Status for open projects for gsoc

Tue Mar 2 22:00:30 UTC 2021

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/20210302/0b0f81ff/attachment-0001.html>