GSoC project: #3850 Modular Network Stacks

[Vijay Kumar Banerjee]

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.

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.


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/c3cb2197/attachment.html>