This is the mail archive of the
mailing list for the Elix project.
Re: First Comments on the EL/IX API Draft Specification
- To: joel dot sherrill at OARcorp dot com
- Subject: Re: First Comments on the EL/IX API Draft Specification
- From: RANDALL_LOOMIS at densolabs dot com
- Date: Thu, 9 Dec 1999 12:19:11 -0800
- cc: Paul Beskeen <paulb at cygnus dot co dot uk>,elix at sourceware dot cygnus dot com
Gave the EL/IX White paper and EL/IX API Draft Specification a couple reads
My first issue is with the white paper, the paragraph:
> This is intended to be an application level standard and we will not
attempt to provide any
> device driver compatibility, no /dev, etc. We will also avoid all
terminal I/O support (see the
> I/O discussion below).
> EL/IX includes BSD sockets (as part of 1003.1g), which
should take care of many I/O
> requirements. We also provide POSIX 1003.1 file I/O
facilities which can operate on
> network drives, flash file systems, RAM and ROM disks,
and even real hard disks. But
> beyond these devices, we really want to support some
kind of abstraction layer that can be
> used to describe a wide range of custom hardware
devices that will enable embedded
> applications to be ported across embedded Linux, eCos,
and other operating systems that
> support EL/IX. For now, the specification of that
abstraction layer remains to be defined. In
> particular, the /dev part of the file system hierarchy
is currently excluded from the EL/IX
> proposal. Since I/O is so fundamental to most uses of
embedded systems, and since there is
> so much variety that must be supported, some sort of
abstraction layers need to be defined,
> which is a subject for the next section.
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
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.
From my first read through of the API Draft Specification, I believe it
should cite the reference numbers for each of it's entries.
kill() [POSIX 1003.1-1990 126.96.36.199]
fopen() [ANSI X3.159-1989 188.8.131.52] [ISO 9899:1990 184.108.40.206] [POSIX
This will make it much easier to plainly see the origin of the function
and refer to the authorative material(s).
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".
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