libio preparation for file systems

[Brian Cuthie]

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.

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.

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. 

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.

Cheers,
Brian

-----Original Message-----
From:	qqi at world.std.com [SMTP:qqi at world.std.com]
Sent:	Monday, February 23, 1998 10:58 PM
To:	rtems-list at oarcorp.com
Subject:	Re: libio preparation for file systems

> 
> 
> Hi,
> 
> I am beginning to look at adding the infrastructure for
> a more robust name space in RTEMS.  libio was orignally
> designed to map device names into major/minor pairs and
> pass IO request through to device drivers.  Since that
> time, it has been augmented to support sockets.
> 
> I would like to start getting the infrastructure in place
> to be able to mount file systems, walk directory trees
> of "/dev", etc.  Essentially have a better "logical
> file system."
> 
> Right now, I am looking at the way this is done in various
> free UNIces (Linux and NetBSD).  I would like suggestions
> on what capabilities you folks would like to see in
> this area.  If you have ideas about possible implementations 
> we could look at.
> 
> I hope this opens a discussion.

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.

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.


> --joel


Aleksey