libio preparation for file systems
Erik Ivanenko
erik.ivanenko at utoronto.ca
Tue Feb 24 15:55:19 UTC 1998
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
>
More information about the users
mailing list