libio preparation for file systems

Joel Sherrill joel at oarcorp.com
Tue Feb 24 15:19:47 UTC 1998



On Tue, 24 Feb 1998, Eric Norum wrote:

> I think "/dev/console" is good.  After 20-odd years of poking around  
> operating system code I am confident that a uniform namespace is the  
> way to go.  It doesn't have to be that expensive in speed or space,  
> either.  The present libio scheme is almost good enough (cf. the  
> /TFTP/host/filename driver for TFTP file transfers) but has some  
> rough edges and a few missing entries (no stat() entry).

I started out thinking of doing a major replacement and now am leaning
toward an enhancement/cleanup.

> On major argument in favour of a common namespace is that it lets us  
> leverage existing C stdio library code and other existing source.

This is probably the biggest argument for having POSIX-ish semantics.

Also some of the POSIX API does require a name space.  To add much more
POSIX functionality will require a better name space.

> > 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.
> 
> Actually, it's a `real-time *executive*' now.  Adding filesystem  
> support (and perhaps memory protection) would bring it into the range  
> of a real-time operating system.

:)  

> > 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.
> >
> 
> I can happily live without the hassles (and often the overhead) of  
> memory protection in the applications I'm working on.   I'm against  
> anything that adds to the context switch time :-)  Actually, I expect  
> that some kind of memory management is going to be required for more  
> modern processors that need it to be able to use cache.  Once that's  
> required I don't see much more effort to make protection work, too.

We would try to add this support in a manner which would not impose it on
every application.  

I know that on the PPC603e, some minor setup in the BSP initialization
lets you avoid having to do much else with the MMU.  The biggest problem
is the interaction of caching with emulators. :(

--joel





More information about the users mailing list