GSoC 2012
Sebastian Huber
sebastian.huber at embedded-brains.de
Sun Mar 25 20:59:19 UTC 2012
On 25/03/12 21:57, Julien Delange wrote:
> On Sun, Mar 25, 2012 at 5:35 PM, Joel Sherrill
> <joel.sherrill at oarcorp.com> wrote:
>> The main advantage is that it is small and gives you TCP/IP
>> stack capabilities in a lower footprint.
> I understand that point but on the other hand, can we afford to
> maintain two network stacks ? In particular, these two stacks should
> be compatible with the underlying drivers and testing/maintainance
> efforts would be more consequent with two stacks. As the libbsd
> project partly aims at providing a new stack, I am just wondering if a
> GSOC project that would focus on some part of the libbsd project would
> also make sense (with a clear definition of what should be
> integrated/done). However, please do not take it hard : if there is a
> clear reason/justification for having two separate stacks, let's go
> :-)
These two network stacks target different applications and/or hardware.
They are in most cases not alternatives. Using lwIP on RTEMS is a
trivial undertaking thus I don't think this is suitable for a GSoC
project. The lwIP is highly configurable and the difficult thing is to
create a configuration which is best for a particular application. It
is possible to write a network interface driver that provides some
functionality for both stacks, but you have to keep in mind that the
buffer management is different in both stacks (the complex part of the
driver). I consider it a waste of time to provide a compatibility
layer. I see also no benefit in integrating the lwIP into the RTEMS
source code (how would you configure the lwIP stack?). It makes more
sense to place the basic RTEMS lwIP port into the lwIP sources.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list