GSoC project: #3850 Modular Network Stacks

Sun Mar 21 19:35:55 UTC 2021

On 21/03/2021 18:53, Joel Sherrill wrote:
> 
> 
> On Sun, Mar 21, 2021, 12:47 PM Vijay Kumar Banerjee <vijay at rtems.org 
> <mailto:vijay at rtems.org>> wrote:
> 
>     Hi Rajiv and Joel,
> 
>     On Sun, Mar 21, 2021 at 9:06 AM Joel Sherrill <joel at rtems.org
>     <mailto:joel at rtems.org>> wrote:
>      >
>      >
>      >
>      > On Sun, Mar 21, 2021, 9:20 AM Rajiv Vaidyanathan
>     <rajiv.vaidyanathan4 at gmail.com
>     <mailto:rajiv.vaidyanathan4 at 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/
>     <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 
> <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library>

If it works with the zynq qemu BSP, I think that would be great for that 
kind of stuff. That BSP is always great for debugging (although most 
likely there will be few C-Code-Work in this repo) because you don't 
need extra hardware.

> 
> The other top alternative is the PC.

PC is hard for debugging. I never searched but I think you most likely 
don't find many with JTAG connectors ;-)

Beagle could be an alternative for real hardware. I found at least one 
lwip driver for that.

> 
> 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.

If there is a driver for one of the supported boards, that would be a 
nice target too. Most of the STM boards have debuggers already on board.

Best regards

Christian

> 
> 
>     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 at rtems.org <mailto:devel at rtems.org>
>      >> http://lists.rtems.org/mailman/listinfo/devel
>     <http://lists.rtems.org/mailman/listinfo/devel>
>      >
>      > _______________________________________________
>      > devel mailing list
>      > devel at rtems.org <mailto:devel at rtems.org>
>      > http://lists.rtems.org/mailman/listinfo/devel
>     <http://lists.rtems.org/mailman/listinfo/devel>
> 
> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 