GSoC project: #3850 Modular Network Stacks
Rajiv Vaidyanathan
rajiv.vaidyanathan4 at gmail.com
Thu Apr 1 04:14:02 UTC 2021
Dear mentors,
Thank you for providing information regarding the project. I have started
making the proposal for this ticket. I'll share it once I have a draft of
it ready.
Thanks and regards,
Rajiv
On Mon, 22 Mar 2021 at 21:43, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Mon, Mar 22, 2021, 10:23 AM Christian Mauderer <contact at c-mauderer.de>
> wrote:
>
>> Hello Rajiv,
>>
>> Am 22.03.21 um 16:11 schrieb Rajiv Vaidyanathan:
>> > Dear mentors,
>> >
>> > Thankyou for providing information about the project. I want to pursue
>> > this as my GSoC project. From the above discussion, I understand that
>> > the following has to be done:
>> > 1. Collecting existing lwip drivers for BSPs and writing new ones.
>> > 2. Adding config files for driver management and also add lwip to the
>> > choice of networking stacks for RTEMS.
>> > 3. Write tests, examples and documentation
>> >
>>
>> The main point will be to create a build repo for lwip similar to the
>> repo for libbsd or the legacy stack (that is currently work in
>> progress). That repo should contain maybe one or two drivers as an
>> example how they should be integrated into the repo. You don't have to
>> find all possible drivers for all BSPs.
>>
>> That repo should contain tests and there should be at least basic
>> documentation how to use it. More documentation is better ;-)
>>
>> > Please let me know if I am missing anything.
>> >
>> > I have the following queries:
>> > 1. Should I buy a Beaglebone or can I do everything with QEMU? I have a
>> > Raspberry Pi 3B+. Can I use it for hardware testing instead?
>>
>> Basically every BSP should work as long as you find a lwip driver that
>> can work with it. I would suggest to look at the xilinx_zynq_a9_qemu and
>> whether you can find a driver for that. It works well with libbsd and an
>> emulated "cadence_gem" network interface. If you find a lwip driver for
>> that, it would be easy to debug that.
>>
>
> I'm prone to say the first focus should be on drivers that we can test
> with simulators specifically qemu. That puts the Zynq, MPSoC, and PC high
> on the list. My second tier would be those we know have users now which is
> the STM H7 and whatever Alan Cudmore is using. For that tier, it should
> have just be helping merge and letting them test.
>
> Focusing on what can work on qemu and what users are actively using lwip
> on now should result in having a solid core of drivers to build from in the
> future. And it should avoid the pain of debugging a driver on real hardware
> while leaving the project with some that are easy to test.
>
>
>> If you want to use a Raspberry, that is OK too. But I'm not entirely
>> sure whether RTEMS run well out of the box on Raspberry 3B+. So please
>> test that before you focus too much on that platform. Also note that
>> debugging on a Raspberry needs extra hardware (same is true for
>> debugging on a Beagle). You most likely won't need too much debugging of
>> applications but it's nice to have it as a fall back if something
>> doesn't work.
>>
>
> I do not think anything newer than a raspberry 2 works without addressing
> some issues. This could easily turned into a time sucker that will have no
> benefit to having an lwip package.
>
>>
>> > 2. I have cloned the rtems-lwip repository. Is there any open issue and
>> > documentation I can look into to get more understanding about this
>> repos
>> > and the project in general?
>>
>> It's a personal repo of Vijay. So he might can give you some information
>> about it. I don't think that there is much documentation.
>>
>> Best regards
>>
>> Christian
>>
>> >
>> > Thanks and regards,
>> > Rajiv
>> >
>> > On Mon, 22 Mar 2021 at 01:06, Christian Mauderer <oss at c-mauderer.de
>> > <mailto:oss at c-mauderer.de>> wrote:
>> >
>> >
>> >
>> > 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>
>> > > <mailto: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>
>> > > <mailto: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>
>> > > <mailto: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/>
>> > > <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
>> >
>> >
>> > >
>> > <
>> 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>
>> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>> > > >> http://lists.rtems.org/mailman/listinfo/devel
>> > <http://lists.rtems.org/mailman/listinfo/devel>
>> > > <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>
>> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>> > > > http://lists.rtems.org/mailman/listinfo/devel
>> > <http://lists.rtems.org/mailman/listinfo/devel>
>> > > <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 <mailto:devel at rtems.org>
>> > http://lists.rtems.org/mailman/listinfo/devel
>> > <http://lists.rtems.org/mailman/listinfo/devel>
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210401/2a11e74c/attachment-0001.html>
More information about the devel
mailing list