Status for open projects for gsoc

[Dev Agrawal]

It's quite interesting, how can I proceed with lwip integration?
What will be a good start?


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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210304/bdea0bfd/attachment-0001.html>