libio preparation for file systems

[Eric Norum]

Brian Cuthie <brian at systemix.com> wrote:
> 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.

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

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

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

But a common namespace makes it easier to use driver code from other  
systems, lessens the learning curve for new programmers, and makes  
it easier to use existing library code.

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


---
Eric Norum                                 eric at skatter.usask.ca
Saskatchewan Accelerator Laboratory        Phone: (306) 966-6308
University of Saskatchewan                 FAX:   (306) 966-6058
Saskatoon, Canada.