libio preparation for file systems

[Joel Sherrill]

On Mon, 23 Feb 1998, Quality Quorum wrote:

> Oh, please, let us keep it as simple as moo. Simplicity and performance
> are at premium in embedded world - and they will suffer as a
> result of improving device abstractions.

I agree wholeheartedly.   This is a necessary part of having more
POSIX-ish semantics but it could come at a high cost.  While I am looking
at the "big boys", I am also trying to figure out exactly what would
have to be done to the current scheme to get more functionality.

I waded through the Linux inode structure and open code yesterday
afternoon.  The inode structure looks to be fairly large and the open code
is pretty complex.  I know some space and complexity is necessary but that
was a bit much for my tastes.

> Just as an exmaple count what percentage of file I/O flags is not
> supported  currently by /dev/console. It is OK as long as we all
> implicitly know what console can and cannot do, but once we will get
> into device abstraction, all devices would have to support common 
> functionality, which can (a) affect performance, (b) be a severe 
> overkill in many many cases.

The termios console support is a pretty good balance.  It offers the
basic functionality expected without imposing too much of a burden.  

Let me state right now that I do not want RTEMS to become a large boat
anchor. :)  I want to keep this part of the system as small and simple as
possible but it needs more functionality.  Especially as discussions of
file systems are starting to become serious.  Plus other areas of POSIX
require a "name space" -- for one message queues have real names.

This is a tough problem.  I think most of the source on the Net is too
heavy for RTEMS.

--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