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

[RANDALL_LOOMIS@densolabs.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
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.  :)