EL/IX spec review, status

EL/IX spec review, status

[Michael A. Olson]

Hi,

Last week I sent a message on the draft EL/IX API spec to this
mailing list, and have seen no response.  My message was pretty
long-winded, but boiled down to a single question:  Is there
any chance that the shared memory support would move from
EL/IX level 4 to EL/IX level 3?  As a vendor, this would let
me sell product on OSes that provide the level 1 or level 3
interfaces, instead of just levels 1 and 4.

There hasn't been any traffic on the list except for my message
since late December.  What's the current status of the draft
specification review?  Is there any schedule for public release
of a reference implementation on eCos?

					mike

Re: EL/IX spec review, status

[Peter Buechler]

On Tue, 18 Jan 2000, Michael A. Olson wrote:

> Last week I sent a message on the draft EL/IX API spec to thismailing list,
> and have seen no response.  My message was pretty long-winded, but boiled down
> to a single question:  Is there any chance that the shared memory support
> would move from EL/IX level 4 to EL/IX level 3?  As a vendor, this would let
> me sell product on OSes that provide the level 1 or level 3
> interfaces, instead of just levels 1 and 4.

I'm just lurking here, but your suggestion seemed reasonable to me. Anybody
else?
-- 
Pete Buechler   peterb@suse.com

Re: EL/IX spec review, status

[Bas Valkema]

> On Tue, 18 Jan 2000, Michael A. Olson wrote:
>
> > Last week I sent a message on the draft EL/IX API spec to thismailing
list,
> > and have seen no response.  My message was pretty long-winded, but
boiled down
> > to a single question:  Is there any chance that the shared memory
support
> > would move from EL/IX level 4 to EL/IX level 3?  As a vendor, this would
let
> > me sell product on OSes that provide the level 1 or level 3
> > interfaces, instead of just levels 1 and 4.
>
> I'm just lurking here, but your suggestion seemed reasonable to me.
Anybody
> else?
> --

Sure, but what would be the difference between level 3 & 4 if the change is
conducted? (sorry had no time to study the spec carefully.. ;-)

Bas Valkema bvalkema@knowhowww.nl

Re: EL/IX spec review, status

[Michael A. Olson]

At 11:19 PM 1/18/00 +0100, you wrote:

> Sure, but what would be the difference between level 3 & 4 if the change is
> conducted? (sorry had no time to study the spec carefully.. ;-)

Level 4 right now has a bunch of system call interfaces not in
level 3.  They include:

	setuid/setgid
	process group support
	filesystem-based mutex support
	password and group database operations
	semaphores
	mapped memory
	shared memory
	some non-standard stream support
	popen() and friends
	named interfaces (if_nametoindex and friends)
	pty and raw terminal support
	common signal handling functions
	interfaces to spawn and manage processes

and just a couple of others.  The spec claims that the difference
between 3 and 4 is that 3 is multi-process and 4 is full Linux.
My argument is that shared memory is a useful abstraction for
multi-process, and belongs there.

The rest of the level 4 interfaces look right to me, based on
the designed differences between 3 and 4.

					mike
		

Re: EL/IX spec review, status

[Nick Garnett]

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

> My argument is that shared memory is a useful abstraction for
> multi-process, and belongs there.
>

Thanks for your comments.

You are right about this, we started off trying to be as ruthless as
possible in taking things out of the APIs. The shared memory
interfaces were one of those things that I was not sure
about so I followed the old adage - "When in doubt, leave it out".

The POSIX 1003.13 Real Time Profiles document adds shared memory
objects and memory mapped files to its Realtime Controller
profile. This is roughly equivalent to our level 2. I still need time
to evaluate these profiles against EL/IX, but we might end up with the
shared memory stuff at level 2.

I have provisionally moved all the shared memory stuff into level 3 in
my current working version of the spec.

-- 
Nick Garnett
Red Hat, Cambridge, UK