<div dir="ltr"><div class="gmail_default" style="font-family:garamond,serif;font-size:small">It's quite interesting, how can I proceed with lwip integration? </div><div class="gmail_default" style="font-family:garamond,serif;font-size:small">What will be a good start?</div><div class="gmail_default" style="font-family:garamond,serif;font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 3, 2021 at 3:30 AM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 2, 2021 at 2:59 PM Vijay Kumar Banerjee <<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Mar 2, 2021 at 1:46 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Mar 2, 2021 at 1:50 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>><br>
>> On Tue, Mar 2, 2021 at 12:37 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Tue, Mar 2, 2021 at 12:47 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>> >><br>
>> >> On Tue, Mar 2, 2021 at 11:25 AM Dev Agrawal <<a href="mailto:dev9893186747@gmail.com" target="_blank">dev9893186747@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> > Hello everyone,<br>
>> >> > I am interested in contributing to a few topics but I don't know what is the current status and future enhancements you are looking for so if you can guide me it would be a big help.<br>
>> >> ><br>
>> >> > 1. #3333  Automate Conversion of Newlib Markup to Sphinx : To begin with the sphinx-quickstart process, doI have to make a build directory under the source directory which I made during the hello world task or normal root directory?<br>
>> >> ><br>
>> >> This is done in a different repo: <a href="https://git.rtems.org/rtems-docs/" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-docs/</a><br>
>> >> @Joel Sherrill Do you know what is status on this project?<br>
>> ><br>
>> ><br>
>> > The script to do the conversion was finished by the student. I experimented<br>
>> > with including the generated output in our POSIX guide. But we never figured<br>
>> > out how to incorporate running it as part of rtems-docs in maintainer mode. We have<br>
>> > a process issue there and defining when the output is regenerated.<br>
>> ><br>
>> OK, then I guess there isn't enough coding work to justify a GSoC<br>
>> anymore? I will update that ticket. Where is the conversion script<br>
>> located?<br>
><br>
><br>
> <a href="https://github.com/dh0072/NewlibMarkup2SphinxConverter" rel="noreferrer" target="_blank">https://github.com/dh0072/NewlibMarkup2SphinxConverter</a><br>
><br>
> I wrote a simple script to driverunning that over newlib and generating<br>
> rst files for each service documented in newlib.<br>
><br>
> We need an accepted technical solution for regenerating them and<br>
> organizing the output in our manual. This shouldn't be hard.<br>
><br>
> We got wrapped around the axle discussing could we automatically<br>
> trigger regeneration on updates to newlib. When would it happen?<br>
> I'm prone to think that newlib's documentation changes so infrequently,<br>
> that picking it up sporadically and as part of going slushy before branching<br>
> is probably sufficient.<br>
><br>
> Technically, the waf could have a maintainer mode where is passed<br>
> a source directory for newlib and triggers regeneration if a source file<br>
> has changed. When maintainer mode is run is the question. But we need<br>
> the maintainer mode settled first.<br>
><br>
>><br>
>> >><br>
>> >><br>
>> >> > 2. #3850 Modular Network Stacks :<br>
>> >> ><br>
>> >> This project is currently being worked on by a developer. @Vijay Kumar<br>
>> >> Banerjee do you think there is anything that a student might be able<br>
>> >> to contribute toward this effort under a GSoC Project?<br>
>> ><br>
>> ><br>
>> > +1<br>
><br>
><br>
> Answering myself. This project has a lot of pieces and I'm sure Vijay could<br>
> use help on the drivers that we know can be tested on simulators and cheap<br>
> hardware. I think Vijay would have to have a repo and lwip building at least to<br>
> be able to leverage help on the list of drivers we have collected.<br>
><br>
> I'd want to be sure that enough were testable on a simulator to be a good<br>
> project. Getting things to compile isn't enough for GSoC. But I think<br>
> we might have 3-4 NICs identified for LWIP with BSPs that run on Qemu.<br>
><br>
Hi Joel,<br>
<br>
Thanks for adding the note.<br>
<br>
Dev: Ticket #3850 consists of two major tasks, one was shifting the<br>
legacy networking stack out of the rtems.git repo, which I recently<br>
completed and it's yet to be merged. I don't think there's enough work<br>
for the legacy stack that can make a GSoC project.<br>
The other major task is the lwip integration. I have just started<br>
working on it and I think this task has enough for two GSoC projects<br>
(especially with the new shorter format of GSoC) so if it really<br>
becomes a GSoC project, I think it needs to be divided into a bunch of<br>
sub-tasks but we haven't decided such tasks. As Joel mentioned above,<br>
I could certainly use some help during the testing of the drivers but<br>
I'm not sure if the repo would be totally up and running before the<br>
GSoC application period is over. This might become an issue for your<br>
GSoC application if we don't have a proper set of tasks decided for<br>
you. Making the repo itself can be a task though, but I'm already<br>
working on it. :)<br></blockquote><div><br></div><div>If you can build the stack and one driver, I would say the other </div><div>drivers could be split into work packages. You could bring up one driver</div><div>and leave others for students. </div><div><br></div><div>With GSoC Students  getting first priority on the ones for simulators. Gedare </div><div>and I have been chatting and I think we have multiple PC ones (SMC, e1000)</div><div>zynq and aarch64 which could be tested on qemu. We need to make </div><div>master list and how the drivers we think are desirable can be tested</div><div><br></div><div>I also found Beagle and Pi drivers which require (cheap) hardware.[1]</div><div><br></div><div>The others would be compile only AFAIK. </div><div><br></div><div>There is always the Pi3/4 BSP update issue as a distinct project.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Best regards,<br>
Vijay<br>
<br>
> --joel<br>
><br>
>><br>
>> >><br>
>> >><br>
>> >> > What would be a good start for these projects?<br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > devel mailing list<br>
>> >> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>
</blockquote></div>