GSoC project: #3850 Modular Network Stacks
oss at c-mauderer.de
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/
> 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.
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.
> 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,
> > 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
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org <mailto:devel at rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> devel mailing list
> devel at rtems.org
More information about the devel