public inbox for elix@sourceware.org
 help / color / mirror / Atom feed
* Announcing availability of the EL/IX API Draft Specification
@ 1999-12-08 13:28 Paul Beskeen
  1999-12-09 10:55 ` First Comments on " Joel Sherrill
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Beskeen @ 1999-12-08 13:28 UTC (permalink / raw)
  To: elix

Hi All,

Please check out the EL/IX website http://sourceware.cygnus.com/elix/ for the
first public draft of the EL/IX Base API Specification. Choose from HTML, PDF
or PS formats according to taste.

Once digested, please feel free to send in your comments on the draft and
engage in discussions on the general EL/IX mailing list
elix@sourceware.cygnus.com You can add yourself to this mailing list from the
main EL/IX web pages.

Enjoy!
Paul.


^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: First Comments on the EL/IX API Draft Specification
@ 1999-12-09 12:27 RANDALL_LOOMIS
  0 siblings, 0 replies; 7+ messages in thread
From: RANDALL_LOOMIS @ 1999-12-09 12:27 UTC (permalink / raw)
  To: joel.sherrill; +Cc: Paul Beskeen, elix

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.













^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: First Comments on the EL/IX API Draft Specification
@ 1999-12-16 10:41 Nick Garnett
  0 siblings, 0 replies; 7+ messages in thread
From: Nick Garnett @ 1999-12-16 10:41 UTC (permalink / raw)
  To: elix

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

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.


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

This looks like a good idea (unfortunately since I will have to go
through and install the references!). The POSIX section already
follows the 1003.1 document, so we could probably get away with
per-subsection references. The C library section could be reorganized to
separate out the ANSI/ISO C standard into a similarly structured
hierarcy. Of course this does not help with functions that are in
multiple specs.

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

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

If you eliminate the locking functions then the only use for fcntl()
is the F_DUPFD function and looking at some flags. Most of the flags
are either irrelevant to embedded apps, or not really very
interesting, which only leaves the F_DUPFD function. Since most of
what is wanted for this kind of thing is already handled by dup()  and
dup2(), it was decided to get rid of the whole function.

It really does not matter that dup() and dup2() are implemented in
terms of fcntl(), it can still be there, just not part of the portable
API. Also, the fact that a header file is now named after a
non-existent function is unfortunate, but cannot be helped.

-- 
Nick Garnett           mailto:nickg@cygnus.co.uk
Cygnus Solutions, UK   http://www.cygnus.co.uk

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: First Comments on the EL/IX API Draft Specification
@ 1999-12-22 12:50 RANDALL_LOOMIS
  1999-12-23  4:08 ` Nick Garnett
  0 siblings, 1 reply; 7+ messages in thread
From: RANDALL_LOOMIS @ 1999-12-22 12:50 UTC (permalink / raw)
  To: Nick Garnett; +Cc: elix

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~1999-12-23  4:08 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-08 13:28 Announcing availability of the EL/IX API Draft Specification Paul Beskeen
1999-12-09 10:55 ` First Comments on " Joel Sherrill
1999-12-16 10:05   ` Nick Garnett
1999-12-09 12:27 RANDALL_LOOMIS
1999-12-16 10:41 Nick Garnett
1999-12-22 12:50 RANDALL_LOOMIS
1999-12-23  4:08 ` Nick Garnett

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).