libio preparation for file systems

[Joel Sherrill]

On Tue, 24 Feb 1998, Brian Cuthie wrote:

> I agree.  If I want UNIX on my embedded board, then I'll run it.   Even
> now in RTEMS it seems kind of silly that there's a name, "/dev/console"
> for the console device.  A constant identifier, compiled into the
> application from a header file, would do just fine.

/dev/console is a constant identifier.  :)

The reason it is done this way is to make it possible to use C Library
calls on devices.  You can actually register another serial device and do
IO to it. 

> The only reason devices are named in UNIX is because programs are loaded
> onto machines whos configurations may have changed since they were
> compiled.  Therefore, it's necessary to abstract the platform from the
> application through the API.  RTEMS doesn't have this problem since
> everything is built for the target and linked into the RTEMS image.

But even though most of the code used in RTEMS applications is custom, a
lot of the infrastructure is freely available.  Chris Johns has been
working with ncurses.  The more POSIX-ish or POSIX-lite functionality
RTEMS has, the easier it is to move freely available code to RTEMS.

As time goes on, it will be nice to see more free SW  like TCL, network
clients/services, etc. run on RTEMS.  Having better POSIX compliance is a
necessity to make this happen easily.

> I applaud the efforts of Joel and OAR.  But, rather than try to build
> the wrong "me too" features into RTEMS, let's keep it the great RTOS it
> is by keeping it an RTOS. 

Agreed.  There are application profiles in the POSIX standard set.  We
have no intention of ever "growing up" too much.  RTEMS will always follow
the single process model.  

And adding layers/more functionality is not bad as long as it does not
become part of the minimum requirements.  I hope it does not.

As numerous people have pointed out over the years, keeping things small
is important.  That means not letting the BSP have references which pull
in stuff and not letting the support libraries pull in too much code.

> Now, Joel, if you have some time on your hands...  A really nice featre
> in RTEMS would be process memory protection.  Much more useful in an
> embedded OS than device names, IMHO.

This is a very useful feature in a number of domains.  In fact, the
user stack allocation hooks were provided for a user who wanted to trap
when the stack overflowed.  His BSP allocated the memory and mapped it
such a way that an overflow or underflow caused a page fault.

This is a useful feature and we are not opposed to implementing it in the
future.

--joel
Joel Sherrill                    Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985