GSoC 2012

[Joel Sherrill]

On 03/25/2012 02:43 AM, Julien Delange wrote:
> On Sun, Mar 25, 2012 at 4:06 AM, Kevin Polulak<kpolulak at gmail.com>  wrote:
>> I've just uploaded the (very early) rough draft of my project proposal to
>> Google Docs and shared it with Joel. I've email confirmed my new wiki
>> account and once it has been approved, I'll add my proposal to the list on
>> the wiki.
> Hi Kevin,
>
> I do not have access to your proposal right now. But why do not
> contribute to the libbsd project ? Since we are several working on
> these, your contribution may also support us and make it better and
> maybe available for the next RTEMS release.
>
The FreeBSD TCP/IP stack upgrade effort (rtems-libbsd.git) is certainly
is more important today than LWIP is to the project.  There is a
lot to do even with OAR working on bringing up a couple of BSPs
and NICs.

The project page is:

http://wiki.rtems.org/wiki/index.php/TCP/IP_update

I added the bullets last week so if you need more detail
on them, please ask.
> The thing is that I do not clearly see the advantage of having two
> different stacks within RTEMS. Is there additional capabilities from
> LWIP that are missing in the BSD stack? In other words, it is possible
> to summarize the main advantages of having this new stack in RTEMS ?
The main advantage is that it is small and gives you TCP/IP
stack capabilities in a lower footprint.

The FreeBSD TCP/IP stack is more capable and industry
standard. I would expect it deals with using the same NIC
drivers on different boards better.

I would give benefit of the doubt on performance but
we know the old FreeBSD stack we are using is capable
of maxing out 100baseT and my few tests on GigE with
ttcp show 80+% of the theoretical bandwidth consumed
on some targets. If there is a performance winner, it
will be FreeBSD.

Make a spectrum from small to large target boards.
FreeBSD stack only fits on targets above point X.
Below that LWIP is your only option.

If you want to write up two proposals, then the mentors
can argue.  But you have to be technically comfortable with
whatever you propose. :)

--joel

> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel