On Sun, Mar 21, 2021, 12:47 PM Vijay Kumar Banerjee <vi...@rtems.org> wrote:
> Hi Rajiv and Joel, > > On Sun, Mar 21, 2021 at 9:06 AM Joel Sherrill <j...@rtems.org> wrote: > > > > > > > > On Sun, Mar 21, 2021, 9:20 AM Rajiv Vaidyanathan < > rajiv.vaidyanath...@gmail.com> wrote: > >> > >> Hello RTEMS community, > >> > >> I found the ticket: Modular Network Stacks interesting. It would be > great if someone can tell the current status of this ticket and what > contributions can be done as a GSoC project. > >> > >> In the prerequisites list given, I have experience in UNIX socket > programming (in C and python), OSI model, basic Wireshark but I don't have > much experience in assembly (I can read assembly but haven't written > assembly code) and device drivers. It would be great if someone can guide > me if I can take up this project. > > > > > > Vijay is the primary mentor for this but I can give you an outline of > what there is to do. > > > > RTEMS historically had a 20 to 25 year old port of the FreeBSD tcpip > stack. This was ipv4 only and the source was included in the main RTEMS > repository. It was enabled or disabled via a configure flag. > > > > There is now the libbsd repository which is a port of the current > FreeBSD with many features and drivers. It has a focus on what we call > source transparency which means that we do not make changes to it unless I > absolutely necessary and try to preserve the original source as much as > possible. This makes it possible to largely update the source using > scripts. We currently track the FreeBSD 12 release branch and their > development version. > > > > With two tcp/ip stacks, it becomes necessary to be able to switch > between them. This project had a first step which was to move the legacy > stack into its own repository. Thanks to Vijay, you can now build RTEMS > without a tcpip stack at all. Then you download and add on the tcp/ip stack > of your choice - legacy or libbsd. > > > > But there's a third tcp/ip stack we are interested in. The lwip stack is > targeted at lower memory profiles and is not as full featured as libbsd. We > need an lwip RTEMS repository which includes lwip, drivers for a variety of > BSPs, its own build system, tests, examples, and any services specific to > lwip. Lwip as a project does not do a good job of providing a central > location for device drivers so the RTEMS lwip repo will be a collection > point. providing a robust set of drivers and keeping track of where they > came from and maintaining Source transparency is key. > > > > This arrangement allows anyone to pick from the set of stacks we > support as long as they deal with the device driver. > > > > The GSoC project you would be proposing is the lwip part. We have a > build of it from a user's application to go by for a working example of the > stack. Probably completely ignore the default lwip build system and uae a > waf build system (Python). > > > The prototype for this repository is ready! > rtems-lwip: https://git.rtems.org/vijay/rtems-lwip.git/ > > This build follows a similar approach to rtems-libbsd and I have also > added a testcase to it, by modifying the networking01.exe from the legacy > repo. > > > I think this is very doable as GSoC project. Vijay already did separate > the legacy stack into its own repository, we have a test case BSP, and > there is a defined patter to follow. > > > I think the first step would be identify a target that we can run on qemu > as well as hardware and focus on that target. Porting that target to LWIP > would involve adding a driver to rtems-lwip, along with a set up to manage > the drivers. For managing different drivers, I propose an ini or yaml > configuration file that can be used by waf scripts to decide which driver > to build for a particular bsp. > I think Gedare and I chatted about this so I had some in mind. Zynq and MPSoC have lwip drivers from xilinx and both run on qemu. https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library The other top alternative is the PC. I can't remember what Alan Cudmore was using but it would be good to at least include it so he can possibly provide feedback on his target. I would expect STM boards also have l whip drivers from the vendor in their device driver kit. > So, roughly the todos for the application phase would be to identify a > potential target and divide the driver work in two phases as per GSoC > schedule. This also involves collecting all the old/previously ported > drivers in one place inside lwip, this will also act as a reference on how > to proceed with the driver for a new target. > Lwip is particularly bad at providing a unified place for drivers. This is something I never wanted to happen with RTEMS. I think a big value of this effort will be collecting drivers that can work with RTEMS bsps. > > Best regards, > Vijay > > > That's the project in a nutshell. Vijay should speak up and add on. > > > >> > >> Thanks and regards, > >> Rajiv > >> _______________________________________________ > >> 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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel