RTEMS evolution was .. Re: bits/wordsize.h

[Eric Norum]

I did the original port of the BSD network stack to RTEMS.

The biggest technical issue was mapping the BSD sleep/wakeup process synchronization mechanism onto RTEMS primitives.  I did this by using the RTEMS event manager and reserving an event for network stack use.   This was made possible by the fact that the BSD code did not make calls directly to sleep/wakeup so I never had to deal with the general case of sleeping on an arbitrary address.   I expect that the same technique would work for more modern BSD code as well.

The other big issue was that the BSD kernel at the time assumed a single-processor, non-preemtible kernel.   This is why I added the network mutex.  Modern BSD code is intended for a symmetric multiprocessing environment so the issues of mapping to RTEMS will be different.

The biggest headaches of the port were in dealing with 'header-file hell' and namespace pollution.  The BSD kernel and applications live in completely separate namespaces and things like malloc/free in the kernel are completely different than their equivalently-named routines in user-land.   In many cases I was able to work around this by using macros when compiling the BVD kernel code.   I tried to keep the BSD kernel source files as intact as possible.  This required all sorts of contortions with header files that overlapped those provided by newlib and/or RTEMS itself.  

A new issue is that many kernel routines now take a pointer to the 'u' structure which has no direct equivalent in RTEMS.  As I recall there aren't many places in the network code that ever dereference this pointer so it might be possible to just sweep this problem under the rug.

All this should be configurable at application build time -- projects that don't need IPv6 shouldn't have to suffer the memory footprint hit of linking in all that code.

I'd be happy to provide suggestions/testing to the limit of the time I have available.

On Apr 19, 2011, at 10:36 PM, Wolfram Wadepohl wrote:

> Networking stack:
> 
> I have the urgent need for a IPinIP tunnel in my future projects. Current stacks from GNU/Linux or BSD support this directly. To get it done there are several choices:
> 
> a) adding a raw socket i/f to current rtems stack and do the IPinIP myself
> b) forcing the update of the networking stack to the current BSD one
> c) changing the RTOS
> 
> 1st choice from technical view is b). But b) has the highest risks, i. e. cost, timeline, robustness.
> 
> My idea is a 'task force' for the update of the networking stack. My part, to be precise the part of the company I work for, could be funds (partly), manpower in programming and testing (not much experience with the BSD stack internals) and project management (very experienced but not in community projects).
> 
> The question is who else is willing to push this effort and will join the task force?
> 
> -- 
> Wolfram Wadepohl, Forschung & Entwicklung
> E&K AUTOMATION GMBH, Werk Reutlingen
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

-- 
Eric Norum
wenorum at lbl.gov