From mboxrd@z Thu Jan 1 00:00:00 1970 From: RANDALL_LOOMIS@densolabs.com To: Nick Garnett Cc: elix@sourceware.cygnus.com Subject: Re: First Comments on the EL/IX API Draft Specification Date: Wed, 22 Dec 1999 12:50:00 -0000 Message-id: <8825684F.0071846B.00@SMTP.DENSOLABS.COM> X-SW-Source: 1999-q4/msg00014.html > 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. The most extreme case of a truely, madly, deeply embedded platform with no OS and no file system still, at least needs to perform some kind of I/O (for now, I will overlook addressing systems so deeply embedded that they take no input and produce no output). A system such as this, with no existing model for device I/O and limited target system resources would have the most to gain from an API standard such as EL/IX which provided a common model for device I/O instead of leaving embedded system's programmer's to constantly re-inventing their own, and allowed initial development to be performed or simulated with a less restrictive target machine. A Level 1 EL/IX API which provides a standard model for device I/O would allow an the same code to run on an 8 bit handheld device with 32K ROM, LCD and keypad, or a Linux machine with the I/O going through a terminal, pseudo-terminal, file, or keyboard and console display running curses. The only differences being in the device driver operations which are executed through the standard EL/IX API calls. Since Linux uses a /dev device file system and because the provisions for I/O offered by POSIX and ISO/ANSI C are based upon the use of file descriptors, I think EL/IX needs to address the issue of file system requirements to support device and file I/O under the API. Maybe this is a separate issue under the heading of "Implementing an EL/IX API" as opposed to a discussion of the API iteslf? > > From my first read through of the API Draft Specification, I believe it > > should cite the reference numbers for each of it's entries. > > This looks like a good idea (unfortunately since I will have to go > through and install the references!). A pretty good source for all the POSIX and ISO/ANSI C references can be found in "The POSIX Programmer's Guide" from O'Reilly. It lists and cites all the POSIX and ISO/ANSI C funtions in order alphabetically and by header file. > > 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. With the idea of EL/IX supporting device I/O, I offer some ways of grouping some of the related functions according to level of file system support provided. d = only need these for file systems which support directories m = only need these for file systems which can be modified p = only need these for file systems which support permissions l = only need these for file systems which support links Directories opendir() d readdir() d readdir_r() d ????where'd this come from? rewinddir() d closedir() d Working Directory chdir() d getcwd() d General File Creation open() creat() m umask() m p link() m l Special File Creation mkdir() m d mkfifo() m File Removal unlink() m rmdir() m d rename() m File Characteristics stat() p fstat() p access() p chmod() m p fchmod() m p chown() m p Input and Output Primitives File Descriptor Manipulation dup() dup2() close() Input and Output read() write() Control Operations on Files fcntl() lseek() The functions without a modifier are required functions to at least support the most primitive ability to obtain and operate on a file descriptor for device I/O. The most primitive file system might just be a static list mapping file descriptors to device driver operations. Lastly, the ioctl() dilemma, including the "Swiss Army Chainsaw" in the API, not completely addressing the special needs of particular I/O devices, or coming up with a better way..... My opinion is to include ioctl() as a required function to support device I/O. My justifications are: 1) Though the ioctl calls themselves wouldn't be portable between Linux and an embedded system, the concept of using ioctl calls for special device manipulation operations would be, so it's probably the most portable over using any other/better solution 2) I couldn't think of a better way. :)