Avoiding (mini) IMFS and libio

Joel Sherrill joel.sherrill at oarcorp.com
Thu Feb 15 15:48:06 UTC 2007


Leon Pollak wrote:
> Hello.
>
> I ask for the excuses ahead if this is not correct:
>
> There was a version of RTEMS ported to CodeWarrior by Steven Johnson in about 
> 1998 which did not included any additional line of code - neither IMFS nor 
> any other. As far as I remember (Steven, am I right?) this was not a simple 
> work in the area of unix/windows adaptation, but IMFS was removed rather 
> easily.
>
> Again excuses - this old version of RTEMS is very far from the today's one and 
> therefore may be very difficult to use this experience...
>
>   
I think your impression is correct.  RTEMS has grown layers over the 
past many years
that were not there in the original code base.  These layers shouldn't 
have hooks that
are terribly difficult to conditionally compile out but I would want to 
be careful that
the resulting system is coherent as an OS profile.

The last time I investigated this issues, I was leaning toward a 
conditional switch to
go between the old device driver name lookup code and the current 
filesystem infrastructure.
At the time, I thought this would still give you named devices and 
should let existing
drivers work without modification.  Assuming the drivers don't need 
termios or some other
infrastructure that would be missing.

Similarly, the original RTEMS code base did not have libcsupport at 
all.  So if you
start looking for connection points, that should be possible to separate 
out conditionally.

And at a finer granularity, the 'unlimited object' support, priority 
inheritance, priority ceiling,
priority based message queues, and other features in the SuperCore may 
be able to
be disabled without terrible difficulty. 

Enabling POSIX includes support for POSIX signals which adds overhead to 
the code space.
Many applications don't use POSIX signals and would be happy to see that 
code disabled.

Some of this may require file splitting to reduce dependencies, others 
may really not be worth
doing since they don't save much.

There are a fair number of these type of point improvements which I 
would like to see
some sponsorship for getting done. 

--joel
> LP
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   




More information about the users mailing list