public inbox for elix@sourceware.org
 help / color / mirror / Atom feed
* New API specification document
@ 2000-02-03  9:57 Nick Garnett
  2000-02-07 15:40 ` Michael A. Olson
  2000-02-08  3:40 ` Arnaud Westenberg
  0 siblings, 2 replies; 5+ messages in thread
From: Nick Garnett @ 2000-02-03  9:57 UTC (permalink / raw)
  To: elix

There is now a new version of the API specification document on the
website. This, hopefully, has absorbed some of the comments we got
back from the first versions and also contains a new section relating
EL/IX to the POSIX.13 Realtime Profiles.

Comments, criticisms and suggestions to this list please.

-- 
Nick Garnett
Red Hat, Cambridge, UK

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

* Re: New API specification document
  2000-02-03  9:57 New API specification document Nick Garnett
@ 2000-02-07 15:40 ` Michael A. Olson
  2000-02-08  2:23   ` Nick Garnett
  2000-02-08  3:40 ` Arnaud Westenberg
  1 sibling, 1 reply; 5+ messages in thread
From: Michael A. Olson @ 2000-02-07 15:40 UTC (permalink / raw)
  To: Nick Garnett; +Cc: elix

I have a question on the revised spec.

Several of the interfaces are marked "o" (optional).  Are these optional
based on the inclusion of a package, like a file system?

Also, some of the interfaces are marked "m" (modified semantics possible).
Generally, it looks like these are intended to provide some basic support
but maybe not the full POSIX semantics of the corresponding calls (for
example, printf and friends).  Is that right?  Is there a minimum
conformance level for these?

					mike

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

* Re: New API specification document
  2000-02-07 15:40 ` Michael A. Olson
@ 2000-02-08  2:23   ` Nick Garnett
  2000-02-08  6:42     ` Michael A. Olson
  0 siblings, 1 reply; 5+ messages in thread
From: Nick Garnett @ 2000-02-08  2:23 UTC (permalink / raw)
  To: Michael A. Olson; +Cc: elix

"Michael A. Olson" <mao@sleepycat.com> writes:

Hi Mike, 

> I have a question on the revised spec.
> 
> Several of the interfaces are marked "o" (optional).  Are these optional
> based on the inclusion of a package, like a file system?

The intention here is to indicate interfaces whose inclusion is under
the direct control of the user, rather than those that as a
consequence of some other configuration option. For example, mkfifo()
is only possible when there is a certain amount of file system
infrastructure present, but the user can also opt not to have FIFOs at
all. Does that make sense?

> 
> Also, some of the interfaces are marked "m" (modified semantics possible).
> Generally, it looks like these are intended to provide some basic support
> but maybe not the full POSIX semantics of the corresponding calls (for
> example, printf and friends).  Is that right?  Is there a minimum
> conformance level for these?
> 

That is exactly right. At present we don't really have a clear idea
what the minimum level for these will be (apart from the null option
of returning ENOSYS, but that is not really very useful). To some
extent this will be configurable; for example, the semantics of the
signal functions will vary depending on what signal handling options
are configured. However, at level one it all depends on the
capabilities of the underlying system.

-- 
Nick Garnett
Red Hat, Cambridge, UK

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

* Re: New API specification document
  2000-02-03  9:57 New API specification document Nick Garnett
  2000-02-07 15:40 ` Michael A. Olson
@ 2000-02-08  3:40 ` Arnaud Westenberg
  1 sibling, 0 replies; 5+ messages in thread
From: Arnaud Westenberg @ 2000-02-08  3:40 UTC (permalink / raw)
  To: elix

Nick Garnett wrote:
> 
> There is now a new version of the API specification document on the
> website. This, hopefully, has absorbed some of the comments we got
> back from the first versions and also contains a new section relating
> EL/IX to the POSIX.13 Realtime Profiles.

Hi,

I noted the "Swiss Army Chainsaw" (as someone called it :-) ) is still
in level 4, is this going to change in the future? If you are going to
provide the filesystem abstraction in level 1, shouldn't ioctl be there
too?

Regards Arnaud

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

* Re: New API specification document
  2000-02-08  2:23   ` Nick Garnett
@ 2000-02-08  6:42     ` Michael A. Olson
  0 siblings, 0 replies; 5+ messages in thread
From: Michael A. Olson @ 2000-02-08  6:42 UTC (permalink / raw)
  To: Nick Garnett; +Cc: elix

At 10:22 AM 2/8/00 +0000, Nick Garnett wrote:

> The intention here is to indicate interfaces whose inclusion is under
> the direct control of the user, rather than those that as a
> consequence of some other configuration option.

Okay, that makes sense.  Thanks.

					mike


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

end of thread, other threads:[~2000-02-08  6:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-02-03  9:57 New API specification document Nick Garnett
2000-02-07 15:40 ` Michael A. Olson
2000-02-08  2:23   ` Nick Garnett
2000-02-08  6:42     ` Michael A. Olson
2000-02-08  3:40 ` Arnaud Westenberg
     [not found] <Michael>
     [not found] ` <A.>
     [not found]   ` <Olson"'s>
     [not found]     ` <message>
     [not found]       ` <of>
     [not found]         ` <"Mon,>
     [not found]           ` <07>
     [not found]             ` <Feb>
     [not found]               ` <2000>
     [not found]                 ` <15:34:03>

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