This is the mail archive of the
mailing list for the Elix project.
Re: First Comments on the EL/IX API Draft Specification
- To: Nick Garnett <nickg at cygnus dot co dot uk>
- Subject: Re: First Comments on the EL/IX API Draft Specification
- From: RANDALL_LOOMIS at densolabs dot com
- Date: Wed, 22 Dec 1999 12:42:21 -0800
- cc: elix at sourceware dot cygnus dot com
> 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
their own, and allowed initial development to be performed or simulated
a less restrictive target machine.
A Level 1 EL/IX API which provides a standard model for device I/O would
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,
file, or keyboard and console display running curses. The only differences
being in the device driver operations which are executed through the
EL/IX API calls.
Since Linux uses a /dev device file system and because the provisions for
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
device and file I/O under the API.
Maybe this is a separate issue under the heading of "Implementing an EL/IX
as opposed to a discussion of the API iteslf?
> > From my first read through of the API Draft Specification, I believe
> > 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
in "The POSIX Programmer's Guide" from O'Reilly.
It lists and cites all the POSIX and ISO/ANSI C funtions in order
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
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
readdir_r() d ????where'd this come from?
General File Creation
umask() m p
link() m l
Special File Creation
mkdir() m d
rmdir() m d
chmod() m p
fchmod() m p
chown() m p
Input and Output Primitives
File Descriptor Manipulation
Input and Output
Control Operations on Files
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
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
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
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
operations would be, so it's probably the most portable over using any
2) I couldn't think of a better way. :)