From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Garnett To: elix@sourceware.cygnus.com Subject: Re: First Comments on the EL/IX API Draft Specification Date: Thu, 16 Dec 1999 10:41:00 -0000 Message-id: X-SW-Source: 1999-q4/msg00006.html > 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