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; 3+ 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] 3+ messages in thread

* First Comments on the EL/IX API Draft Specification
  1999-12-08 13:28 Announcing availability of the EL/IX API Draft Specification Paul Beskeen
@ 1999-12-09 10:55 ` Joel Sherrill
  1999-12-16 10:05   ` Nick Garnett
  0 siblings, 1 reply; 3+ 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] 3+ 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; 3+ 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] 3+ messages in thread

end of thread, other threads:[~1999-12-16 10:05 UTC | newest]

Thread overview: 3+ 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

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