Re: First Comments on the EL/IX API Draft Specification

[Nick Garnett <nickg at cygnus dot co dot uk>]

> It seems to me, that an implementation of a /dev device file system is
> exactly the kind of abstraction layer that can
> be used to enable applications to be ported betweeen OS's.  Also, POSIX
> terminal I/O support seems particularly important
> for unifying terminal/serial I/O implementations  across platforms.  Almost
>  every embedded system has some kind of serial
> port and most that I've seen reinvent their own version of serial I/O
> interface drivers.
> I don't understand why the implementation of a POSIX virtual file system
> with device files and POSIX terminal I/O support to unify
> device I/O and serial I/O implementations wouldn't be crucial for EL/IX to
> be a meaningful API that could sit atop an embedded kernel.

The whole device access area has yet to be addresses, but I largely
agree with you that maybe the /dev model may be the best approach for
portability. Being able to handle all devices within the standard APIs
is very tempting. The real problem is in dealing with devices that do not
fit the pseudo-file model. For many of these all the accesses after
the first open() are handled by ioctl(). This really sucks and it
would be nice to find a better way. I would really like to avoid
having ioctl() in the API at all.


> 
> From my  first read through of the API Draft Specification, I believe it
> should cite the reference numbers for each of it's entries.
> e.g.:
>   kill() [POSIX 1003.1-1990 3.3.2.1]
>   fopen() [ANSI X3.159-1989 4.9.5.3] [ISO 9899:1990 7.9.5.3] [POSIX
> 1003.1-1990 8.2.3.1]
> etc.
>   This will make it much easier to plainly see the origin of the function
> and refer to the authorative material(s).

This looks like a good idea (unfortunately since I will have to go
through and install the references!). The POSIX section already
follows the 1003.1 document, so we could probably get away with
per-subsection references. The C library section could be reorganized to
separate out the ANSI/ISO C standard into a similarly structured
hierarcy. Of course this does not help with functions that are in
multiple specs.

> 
> Under the "General File Creation" heading, the blurb, "These are only
> applicable to file systems that are writable" doesn't
> seem accurate.  Clearly, a read only file can be "opened".
>

Yes, of course. I was really thinking more about creat() and link()
and some of the side effects of open() like changing the access time
on the file. I'll have to make it clearer.

> Under "Control Operations on Files", the fcntl() function is relegated to
> level 2 while other primitive file descriptor and file I/O functions
> are under level 1.  I do not believe you can separate fcntl in this way.
> Many libraries implement dup() and dup2() functions in terms of
> fcntl() calls.  Also, according to POSIX, the fcntl.h header file declares
> the functions:  creat() fcntl() and open() as well as all the O_xxxx
> file open mode flags.  Clearly, POSIX does not intend for these to be
> separated.
> 

If you eliminate the locking functions then the only use for fcntl()
is the F_DUPFD function and looking at some flags. Most of the flags
are either irrelevant to embedded apps, or not really very
interesting, which only leaves the F_DUPFD function. Since most of
what is wanted for this kind of thing is already handled by dup()  and
dup2(), it was decided to get rid of the whole function.

It really does not matter that dup() and dup2() are implemented in
terms of fcntl(), it can still be there, just not part of the portable
API. Also, the fact that a header file is now named after a
non-existent function is unfortunate, but cannot be helped.

-- 
Nick Garnett           mailto:nickg@cygnus.co.uk
Cygnus Solutions, UK   http://www.cygnus.co.uk