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