libio preparation for file systems

[Joel Sherrill]

On Tue, 24 Feb 1998, Rick McBain wrote:

> 1. My vote goes for POSIX enhancements where it makes sense.  I first got
> interested in RTEMS BECAUSE it supported POSIX.  Even if you support a
> limited subset (i.e., not a sanctioned profile), I would say this is a good
> thing at protecting my source code investment.  In my industry, the source
> code tends to live much longer than the choice of OS or processor it runs
> on...

Unless we missed the boat horribly, RTEMS is not all that far off some of
the smaller sanctioned POSIX profiles.  I like to say that RTEMS supports
the POSIX stuff embedded programmers expect. ;)  Whether that matches any
particular profile is another matter.  

> What I hear lots of people saying is that they don't want whatever is done
> to be bloated.  My vote goes here, too. Our embedded applications have much
> less resources than the typical VME CPU board.  Some of our applications are
> desireable to fit in only on-chip flash/SRAM (although probably not
> including a filesystem :)

We do not want RTEMS to get bloated either.  It has been on a growth and
feature addition path for about 2 years now (since around 3.2.1).  I know
of few mechanically oriented things could be done which would reduce
executable sizes.  One of these is to conditionally compile out the
multiprocessing code in single processor configurations.  Another is to
break the executive source files up from "per manager" to "per routine".
Together these would be a big help.  At least 8K of code could be dropped
by the MP trick on the m8k.  RISC CPUs could double that number.

> 2. On memory protection - I agree with Joel.   Supporting cache is quite
> simple, compared to supporting memory protection (we use an MPC860, and I
> could code the cache setup in a day or two). Also, device drivers are much
> more difficult in protected systems.  As with the discussion on filesystems,
> adding memory protection adds an unnacceptable burden  on many embedded
> applications - it should be an optional (not required) item.

There are many types of embedded systems with varying requirements.  RTEMS
aims at the lower end of embedded systems - "deeply embedded".  Some of
these are very safety critical while others are cost conscious.    The
choice of whether or not memory protection  necessary is a functional
application requirements issue.  The performance hit is not all THAT bad
on modern CPUs with integrated MMUs.  But if speed is of concern, then you
don't want the MMU.

Similarly many people disable cache on real-time systems since it
negatively impacts the deterministic performance of the system.  

--joel