From mboxrd@z Thu Jan  1 00:00:00 1970
From: RANDALL_LOOMIS@densolabs.com
To: joel.sherrill@OARcorp.com
Cc: Paul Beskeen <paulb@cygnus.co.uk>, elix@sourceware.cygnus.com
Subject: Re: First Comments on the EL/IX API Draft Specification
Date: Thu, 09 Dec 1999 12:27:00 -0000
Message-id: <88256842.006BBD2F.00@SMTP.DENSOLABS.COM>
X-SW-Source: 1999-q4/msg00004.html

Gave the EL/IX White paper and EL/IX API Draft Specification a couple reads
through.
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).

> I/O

>                    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
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.

>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).

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
separated.