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 <j...@rtems.org> wrote: > > > On Tue, Mar 2, 2021 at 2:59 PM Vijay Kumar Banerjee <vi...@rtems.org> > wrote: > >> 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. :) >> > > 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@rtems.org >> >> >> > http://lists.rtems.org/mailman/listinfo/devel >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
