This is the mail archive of the elix@sourceware.cygnus.com 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]

First Comments on the EL/IX API Draft Specification



> 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


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