libio preparation for file systems

[Erik Ivanenko]

Brian Cuthie wrote:

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

Hear Hear! This would be far preferable to changing an API that is entirely
reasonable in the firstplace.  If it's not broken.....

Erik Ivanenko
Supervisor, Controls Services.



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