Status for open projects for gsoc

Thu Mar 4 17:47:58 UTC 2021

On Thu, Mar 4, 2021 at 10:27 AM Dev Agrawal <dev9893186747 at gmail.com> wrote:
>
> It's quite interesting, how can I proceed with lwip integration?
> What will be a good start?
>

Begin to work with Vijay to scope out some tasks and a plan, and start
to write the proposal toward that plan.

For this work, we will expect competency to work with networking. So
running some network demo on a simulator will strengthen your
proposal. To this end, I would suggest that you and Vijay identify
some qemu-simulated target(s) that you can test out the refactored
legacy networking stack, and some qemu-simulated target(s) that you
can test out the libbsd networking stack. This will  give you some
practical experience to show that you can build and run a networking
stack that already works.

Maybe, an existing lwIP port can also be run with minimal effort, to
help defray the risk that Vijay does not have the lwip repo prepared
before the application period ends that you could still make progress
on lwIP drivers for eventual merging.

My two cents,
Gedare

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