This is the mail archive of the mailing list for the Elix project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

<> writes:

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

I agree with all of this.

Our first efforts at trying to specify device access APIs were to
generate a set of class specific API functions for each class of
device in the same way that POSIX already has class specific functions
for terminals. These were unsatisfactory since they were inflexible,
not scalable and we would have had to invent new APIs for all sorts of
devices. So we decided in the first instance to put this aspect on the
back burner for a while.

> Maybe this is a separate issue under the heading of "Implementing an EL/IX
> API"
> as opposed to a discussion of the API iteslf?


In parallel to this we are investigating what we need to do to eCos to
support EL/IX. The amount of code necessary to provide a
UNIX/Linux-like filename and descriptor IO model is not particularly
large, and is mostly table-driven. It would not be too difficult to
generate a free software infrastructure for all of this stuff that
could be used stand-alone and on top of any 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.
> >
> > 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.

Now, if I could just find a machine-readable copy of that I would be

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

Thanks, this will be useful.

>      readdir_r()         d         ????where'd this come from?

This is a thread safe version of readdir() (POSIX Spec section 5.1.2).
There are a number of such replacement functions for various unsafe C
library functions. 

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

Indeed. Despite my misgivings about having it I have suspected all
along that ioctl() will find its way in for the very reasons you
give. Every device IO system I have ever seen has had an ioctl()-like
interface, either from the start or bolted on later. I fear that we
will have to bow to the inevitable.

Nick Garnett 
Cygnus Solutions, UK

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]