* 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; 6+ 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] 6+ messages in thread
* Re: First Comments on the EL/IX API Draft Specification
1999-12-22 12:50 First Comments on the EL/IX API Draft Specification RANDALL_LOOMIS
@ 1999-12-23 4:08 ` Nick Garnett
0 siblings, 0 replies; 6+ messages in thread
From: Nick Garnett @ 1999-12-23 4:08 UTC (permalink / raw)
To: RANDALL_LOOMIS; +Cc: elix
<RANDALL_LOOMIS@densolabs.com> 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?
Agreed.
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
laughing.
> > > 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 mailto:nickg@cygnus.co.uk
Cygnus Solutions, UK http://www.cygnus.co.uk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: First Comments on the EL/IX API Draft Specification
@ 1999-12-16 10:41 Nick Garnett
0 siblings, 0 replies; 6+ 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] 6+ messages in thread
* First Comments on the EL/IX API Draft Specification
1999-12-09 10:55 ` First Comments on " Joel Sherrill
@ 1999-12-16 10:05 ` Nick Garnett
0 siblings, 0 replies; 6+ messages in thread
From: Nick Garnett @ 1999-12-16 10:05 UTC (permalink / raw)
To: joel.sherrill; +Cc: elix
> Paul Beskeen wrote:
> >
> > 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.
>
> Let me start by saying that a useful and reasonable subset of POSIX for
> embedded systems is very important. The RTEMS Project has long believed
> this type of effort was critical to the success of providing
> compatability
> across a wide range of systems. :)
>
> I have not disgested the entire thing yet but had a handful of questions
> and comments to kick things off.
>
> + Has any analysis been done on how newlib stacks up? The focus seems
> to be
> on glibc.
One of the problems with newlib is that it is not nearly as complete
as glibc. The C library for eCos is based on newlib, and the
differences between newlib and glibc are therefore accounted for
somewhat in what we have left out of the Level 1 spec.
>
> + Where are the *64() functions from? (open64(), read64(), etc.)
>
These are all glibc functions - GNU extensions for 64 bit file
systems. It is not yet clear whether we should make these part of the
main API, make them an option, or get rid of them entirely.
> + How does the networking functionality included related to the POSIX
> Networking
> standard?
Whenever the standard emerges, I am sure that we will adopt it along
with Linux and every other operating system. In the meantime our
definition will be the pragmatic one: whatever Linux does.
>
> + My gut feeling is that there is something meaningful between levels
> 1 and 2. Level 2 appears to include glibc specific functions. I
> think
> there should be a real standard POSIX subset above level one which
> does
> not include "vendor specific" routines.
Maybe. On the other hand this could just be Level 2 with some of the
optional elements left out. We may need to make more of the "vendor
specific" stuff optional for this to work.
Thanks for the comments, and keep them coming.
--
Nick Garnett mailto:nickg@cygnus.co.uk
Cygnus Solutions, UK http://www.cygnus.co.uk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: First Comments on the EL/IX API Draft Specification
@ 1999-12-09 12:27 RANDALL_LOOMIS
0 siblings, 0 replies; 6+ 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] 6+ messages in thread
* First Comments on the EL/IX API Draft Specification
1999-12-08 13:28 Announcing availability of " Paul Beskeen
@ 1999-12-09 10:55 ` Joel Sherrill
1999-12-16 10:05 ` Nick Garnett
0 siblings, 1 reply; 6+ messages in thread
From: Joel Sherrill @ 1999-12-09 10:55 UTC (permalink / raw)
To: Paul Beskeen; +Cc: elix
Paul Beskeen wrote:
>
> 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.
Let me start by saying that a useful and reasonable subset of POSIX for
embedded systems is very important. The RTEMS Project has long believed
this type of effort was critical to the success of providing
compatability
across a wide range of systems. :)
I have not disgested the entire thing yet but had a handful of questions
and comments to kick things off.
+ Has any analysis been done on how newlib stacks up? The focus seems
to be
on glibc.
+ Where are the *64() functions from? (open64(), read64(), etc.)
+ How does the networking functionality included related to the POSIX
Networking
standard?
+ My gut feeling is that there is something meaningful between levels
1 and 2. Level 2 appears to include glibc specific functions. I
think
there should be a real standard POSIX subset above level one which
does
not include "vendor specific" routines.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-12-23 4:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-22 12:50 First Comments on the EL/IX API Draft Specification RANDALL_LOOMIS
1999-12-23 4:08 ` Nick Garnett
-- strict thread matches above, loose matches on Subject: below --
1999-12-16 10:41 Nick Garnett
1999-12-09 12:27 RANDALL_LOOMIS
1999-12-08 13:28 Announcing availability of " Paul Beskeen
1999-12-09 10:55 ` First Comments on " Joel Sherrill
1999-12-16 10:05 ` 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).