On Tue, Mar 2, 2021 at 1:46 PM Joel Sherrill <j...@rtems.org> wrote: > > > > On Tue, Mar 2, 2021 at 1:50 PM Gedare Bloom <ged...@rtems.org> wrote: >> >> On Tue, Mar 2, 2021 at 12:37 PM Joel Sherrill <j...@rtems.org> wrote: >> > >> > >> > >> > On Tue, Mar 2, 2021 at 12:47 PM Gedare Bloom <ged...@rtems.org> wrote: >> >> >> >> On Tue, Mar 2, 2021 at 11:25 AM Dev Agrawal <dev9893186...@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. :) Best regards, Vijay > --joel > >> >> >> >> >> >> >> > What would be a good start for these projects? >> >> > >> >> > _______________________________________________ >> >> > devel mailing list >> >> > devel@rtems.org >> >> > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
