public inbox for elix@sourceware.org
 help / color / mirror / Atom feed
From: Nick Garnett <nickg@cygnus.co.uk>
To: <joel.sherrill@OARcorp.com>
Cc: elix@sourceware.cygnus.com
Subject: First Comments on the EL/IX API Draft Specification
Date: Thu, 16 Dec 1999 10:05:00 -0000	[thread overview]
Message-ID: <po4sdi223z.fsf@balti.cygnus.co.uk> (raw)
In-Reply-To: <384FF975.D34753DA@OARcorp.com>

> 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

  reply	other threads:[~1999-12-16 10:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=po4sdi223z.fsf@balti.cygnus.co.uk \
    --to=nickg@cygnus.co.uk \
    --cc=elix@sourceware.cygnus.com \
    --cc=joel.sherrill@OARcorp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).