GSoC project: #3850 Modular Network Stacks

[Joel Sherrill]

On Sun, Mar 21, 2021, 12:47 PM Vijay Kumar Banerjee <vijay at rtems.org> wrote:

> Hi Rajiv and Joel,
>
> On Sun, Mar 21, 2021 at 9:06 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Sun, Mar 21, 2021, 9:20 AM Rajiv Vaidyanathan <
> 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/
>
> 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 at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> > _______________________________________________
> > 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/20210321/85a7ce55/attachment.html>