Standards Update, IEEE 1003.4: Real-time Extensions

#454

Author: Jeffrey S. Haemer
Date: Wed, 22 Aug 1990 16:09

91 lines
4902 bytes

From:  Jeffrey S. Haemer <jsh@usenix.org>


           An Update on UNIX*-Related Standards Activities

                             August, 1990

                 USENIX Standards Watchdog Committee

          Jeffrey S. Haemer <jsh@usenix.org>, Report Editor

IEEE 1003.4: Real-time Extensions

Rick Greer <rick@ism.isc.com> reports on the July 16-20 meeting in
Danvers, Massachusetts:

Most of the action in the July dot four meeting centered around -- you
guessed it -- threads.  The current threads draft (1003.4a) came very
close to going to ballot.  An overwhelming majority of those present
voted to send the draft to ballot, but there were enough complaints
from the dot fourteen people (that's multiprocessing -- MP) about the
scheduling chapter to hold it back for another three months.
Volunteers from dot fourteen have agreed to work on the scheduling
sections so that the draft can go to ballot after the next meeting, in
October.

Actually, dot four voted to send the draft to ballot after that
meeting in any case, and the resolution was worded in such a way that
a consensus would be required to prevent the draft from going to
ballot in October.  Thus, the MP folks have this one final chance to
clean up the stuff that's bothering them -- if it isn't fixed by
October, it will have to be fixed in balloting.  Some of us in dot
fourteen felt the best way to fix the thread scheduling stuff was via
ballot objection anyway.  Unfortunately, the threads balloting group
is now officially closed, and a number of MP people saw this as their
last chance to make a contribution to the threads effort.  The members
of dot fourteen weren't the only ones to be taken by surprise by the
closure of the threads balloting group.  It seems that many felt that
it would be a cold day in hell before threads made it to ballot and
weren't following the progress of dot four all that closely.  [Editor:
I've bet John Gertwagen a beer that threads will finish balloting
before the rest of dot four.  The bet's a long way from being decided,
but I still think I'll get my beer.]

Meanwhile, the ballot resolution process continues for the rest of dot
four, albeit rather slowly.  There are a number of problems here, the
biggest being lack of resources.  In general, people would much rather
argue about threads than deal with the day-to-day grunt work
associated with the IEEE standards process.  [Editor: The meeting will

__________

  * UNIXTM is a Registered Trademark of UNIX System Laboratories in
    the United States and other countries.

August, 1990 Standards Update        IEEE 1003.4: Real-time Extensions


				- 2 -

be in Seattle, Washington.  Go.  Be a resource.] Many of the technical
reviewers have yet to get started on their sections.  Nevertheless,
proposed resolutions to a number of objections were presented and
accepted at the Danvers meeting.

     [Editor: Rick is temporarily unavailable, but Simon Patience of
     the OSF has kindly supplied these examples:

     The resolved objections were taken from the CRB: replacing the
     event mechanism by ``fixed'' signals, replacing the shared memory
     mechanism by mmap() and removing semaphore handles from the file
     system name space.  Replacing events by signals was accepted; no
     problem here.  Adopting mmap() got a mixed reception, partly
     because some people thought you had to take all of mmap(), where
     a subset might suffice.  The final vote on this was not to ask
     the reviewer to adopt mmap(), which may not not satisfy the
     objectors.  I'd guess the balloting group will eventually hold
     sway here!  Finally, the group accepted abandoning the use of
     file descriptors for semaphore handles, but some participants
     wanted to keep semaphore names pathnames.  The reviewer was sent
     off to rethink the implications of this suggestion.  ]

We should be seeing a lot more of this in Seattle.  Similar comments
apply to the real-time profile (AEP) work.  The AEP group made more
progress over the last three months than the technical reviewers did,
although even that (the AEP progress) was less than I'd hoped.  We're
expecting our first official AEP draft in October.

August, 1990 Standards Update        IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 21, Number 50

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#459

Author: peter da silva
Date: Fri, 24 Aug 1990 03:28

11 lines
947 bytes

From:  peter@ficc.ferranti.com (peter da silva)

My personal opinion is that *anything* that can go into the file system name
space *should*. That's what makes UNIX UNIX... that it's all visible from the
shell...
---
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

Volume-Number: Volume 21, Number 57

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#467

Author: Chip Salzenberg
Date: Mon, 27 Aug 1990 17:51

15 lines
1117 bytes

From:  chip@tct.uucp (Chip Salzenberg)

>     Finally, the group accepted abandoning the use of
>     file descriptors for semaphore handles, but some participants
>     wanted to keep semaphore names pathnames.

Aargh!  Almost everyone realizes that System V IPC is a botch, largely
because it doesn't live in the filesystem.  So what does IEEE do?
They take IPC out of the filesystem!

What sane reason could there be to introduce Yet Another Namespace?
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 65

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#471

Author: Simon Patience
Date: Tue, 28 Aug 1990 11:58

40 lines
2461 bytes

From:  sp@mysteron.osf.org (Simon Patience)

In article <467@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
>From:  chip@tct.uucp (Chip Salzenberg)
>
>>     Finally, the group accepted abandoning the use of
>>     file descriptors for semaphore handles, but some participants
>>     wanted to keep semaphore names pathnames.
>
>Aargh!  Almost everyone realizes that System V IPC is a botch, largely
>because it doesn't live in the filesystem.  So what does IEEE do?
>They take IPC out of the filesystem!
>
>What sane reason could there be to introduce Yet Another Namespace?

The reason for semaphores not being in the file system is twofold. Some
realtime embedded systems do not have a file system but do want semaphores
So this allows them to have them without having to bring in the baggage a
file system would entail. Secondly, as far as threads, which are supposed to
be light weight, are concerned it allows semaphores to be implmented in user
space rather than forcing them into the kernel for the file system.

A good reason for *not* having IPC handles in the file system is to allow
network IPC to use the same interfaces. If you have IPC handles in the
file system then two machines who have applications trying to communicate
would also have to have at least part of their file system name space to
be shared. This is non trivial to arrange for two machines so can you
imaging the problem of doing this for 100 (or 1000?) machines.

I am just the messenger for these views and do not necessarily hold them
myself. They were the reasons that came up during the discussion.

Simon.

  Simon Patience				Phone: (617) 621-8736
  Open Software Foundation			FAX:   (617) 225-2782
  11 Cambridge Center				Email: sp@osf.org
  Cambridge MA 02142				       uunet!osf.org!sp

Volume-Number: Volume 21, Number 68

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#474

Author: Chuck.Phillips
Date: Wed, 29 Aug 1990 14:01

35 lines
2010 bytes

From:  Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)

>>>>> On 28 Aug 90 11:58:40 GMT, sp@mysteron.osf.org (Simon Patience) said:
>>     Finally, the group accepted abandoning the use of
>>     file descriptors for semaphore handles, but some participants
>>     wanted to keep semaphore names pathnames.
>>
>Aargh!  Almost everyone realizes that System V IPC is a botch, largely
>because it doesn't live in the filesystem.  So what does IEEE do?
>They take IPC out of the filesystem!
>
>What sane reason could there be to introduce Yet Another Namespace?

Simon> The reason for semaphores not being in the file system is twofold.
Simon> Some realtime embedded systems do not have a file system but do want
Simon> semaphores...

Simon> A good reason for *not* having IPC handles in the file system is to
Simon> allow network IPC to use the same interfaces.

How about adding non-file-system-based "handles" to an mmap-like interface?
(e.g. shmmap(host,porttype,portnum,addr,len,prot,flags)?)  This could
allow the same interface to be used for network and non-network IPC,
without the overhead of a trap for every non-network IPC transaction.

`Scuse me while I don my flame retardant suit...  :-)

#include <std/disclaimer.h>
--
Chuck Phillips  MS440
NCR Microelectronics 			Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO.  80525   		uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 21, Number 72

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#476

Author: Chip Salzenberg
Date: Thu, 30 Aug 1990 12:31

31 lines
1893 bytes

From:  chip@tct.uucp (Chip Salzenberg)

According to sp@mysteron.osf.org (Simon Patience):
>Some realtime embedded systems do not have a file system but do want
>semaphores.  So this allows them to have them without having to bring
>in the baggage a file system would entail.

I was under the impression that POSIX was designing a portable Unix
interface.  Without a filesystem, you don't have Unix, do you?
Besides, a given embedded system's library could easily emulate a
baby-simple filesystem.

>Secondly, as far as threads, which are supposed to be light weight,
>are concerned it allows semaphores to be implmented in user space
>rather than forcing them into the kernel for the file system.

The desire for user-space support indicates to me that there should be
some provision for non-filesystem (anonymous) IPCs that can be created
and used without kernel intervention.  This need does not reduce the
desirability of putting global IPCs in the filesystem.

>A good reason for *not* having IPC handles in the file system is to allow
>network IPC to use the same interfaces.

Filesystem entities can be used to trigger network activity by the
kernel (or its stand-in), even if they do not reside on shared
filesystems.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 74

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#477

Author: Scott E. Preece
Date: Thu, 30 Aug 1990 15:07

52 lines
3290 bytes

From:  preece@urbana.mcd.mot.com (Scott E. Preece)

| From:  sp@mysteron.osf.org (Simon Patience)

| The reason for semaphores not being in the file system is twofold. Some
| realtime embedded systems do not have a file system but do want semaphores
| So this allows them to have them without having to bring in the baggage a
| file system would entail.
---
I don't care whether they have something that looks like UNIX filesystem
code or not, or whether they have disk drives or not, but I don't think
it's unreasonable to require them to handle semaphore names as though
they were in a filesystem namespace.  Otherwise you're going to end up
with a collection of independent features, each minimally specified so
that it can work without assuming anything else, and anyone with any
sense is going to say "Yuck" and use a real operating system that
provides reasonable integration and for a uniform notion of, among other
things, naming.
---
| ...		 Secondly, as far as threads, which are supposed to
| be light weight, are concerned it allows semaphores to be implmented in user
| space rather than forcing them into the kernel for the file system.
---
Eh?  I don't know what the group has proposed since the ballot, but it
would seem that using a filesystem name only makes a difference when you
first specify you're going to be looking at a particular semaphore,
which shouldn't be a critical path event.  After that you use a file
descriptor, which I think could be handled in user space about as well
as anything else.  In either case you're going to have to go to the
kernel when scheduling is required (when you block or when you release
the semaphore).
---
| A good reason for *not* having IPC handles in the file system is to allow
| network IPC to use the same interfaces. If you have IPC handles in the
| file system then two machines who have applications trying to communicate
| would also have to have at least part of their file system name space to
| be shared. This is non trivial to arrange for two machines so can you
| imaging the problem of doing this for 100 (or 1000?) machines.
---
You're going to have to synchronize *some* namespace anyway, why
shouldn't it be a piece of the filesystem namespace?

A consistent approach to naming and name resolution for ALL global
objects should be one of the basic requirements for any new POSIX (or
UNIX!) functionality.  We should have *one* namespace so that we can
write general tools that only need to know about one namespace.
--
scott preece
motorola/mcd urbana design center	1101 e. university, urbana, il   61801
uucp:	uunet!uiucuxc!udc!preece,	 arpa:	preece@urbana.mcd.mot.com

Volume-Number: Volume 21, Number 75

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#487

Author: Martin Fouts
Date: Wed, 05 Sep 1990 15:46

30 lines
1628 bytes

From:  fouts@bozeman.bozeman.ingr (Martin Fouts)

>>>>> On 24 Aug 90 03:28:06 GMT, peter@ficc.ferranti.com (peter da silva) said:
peter> My personal opinion is that *anything* that can go into the file system name
peter> space *should*. That's what makes UNIX UNIX... that it's all visible from the
peter> shell...

I'm not sure which Unix you've been running for the past five or more
years, but a lot of stuff doesn't live in the file system name space
under various BSD derived systems, nor do the networking types believe
it belongs there.  IMHO neither does a process handle, nor a
semaphore, and don't even talk to me about "named pipes" as an IPC
mechanism.

(Gee, I guess reasonable men might differ on what belongs in the name
space ;-)

Marty
--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd!fouts@ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa

Volume-Number: Volume 21, Number 83

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#489

Author: Doug Gwyn
Date: Thu, 06 Sep 1990 21:03

15 lines
1316 bytes

From:  Doug Gwyn <gwyn@smoke.brl.mil>

In article <488@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
>I'm not sure which Unix you've been running for the past five or more
>years, but a lot of stuff doesn't live in the file system name space
>under various BSD derived systems, nor do the networking types believe
>it belongs there.

Excuse me, but the "networking types" I talk to believe that sockets
were a botch and that network connections definitely DO belong within
a uniform UNIX "file" name space.  Peter was quite right to note that
this is an essential feature of UNIX's design.  In fact there are UNIX
implementations that do this right, 4BSD is simply not among them yet.

Volume-Number: Volume 21, Number 85

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#491

Author: peter da silva
Date: Fri, 07 Sep 1990 02:40

40 lines
2155 bytes

From:  peter da silva <peter@ficc.ferranti.com>

In article <488@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
> > My personal opinion is that *anything* that can go into the file system
> > name space *should*. That's what makes UNIX UNIX... that it's all visible
> > from the shell...

> I'm not sure which Unix you've been running for the past five or more
> years, but a lot of stuff doesn't live in the file system name space
> under various BSD derived systems,

Yes, and there's even more stuff in System V that doesn't live in that
name space. In both cases it's *wrong*.

> nor do the networking types believe
> it belongs there.

Some more details on this subject would be advisable. I'm aware that not
everything *can* go in the file system name space, by the way...

> IMHO neither does a process handle, nor a
> semaphore, and don't even talk to me about "named pipes" as an IPC
> mechanism.

An active semaphore can be implemented any way you want, but it should
be represented by an entry in the name space. The same goes for process
handles and so on.

Named pipes are an inadequate mechanism for much IPC, but they work quite
well for many simple cases. If you're looking at them as some sort of
paragon representing the whole concept, you're sadly mistaken.

Anyway... what is it that makes "dev/win" more worthy of having an entry
in "/dev" than "dev/socket"?
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

Volume-Number: Volume 21, Number 87

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#493

Author: Chip Salzenberg
Date: Fri, 07 Sep 1990 15:23

30 lines
1960 bytes

From:  chip@tct.uucp (Chip Salzenberg)

According to fouts@bozeman.bozeman.ingr (Martin Fouts):
>I'm not sure which Unix you've been running for the past five or more
>years, but a lot of stuff doesn't live in the file system name space ...

The absense of sockets (except UNIX domain), System V IPC, etc. from
the file system is, in the opinion of many, a bug.  It is a result of
Unix being extended by people who do not understand Unix.

Research Unix, which is the result of continued development by the
creators of Unix, did not take things out of the filesystem.  To the
contrary, it put *more* things there, including processes (via the
/proc pseudo-directory).

It is true that other operating systems get along without devices,
IPC, etc. in their filesystems.  That's fine for them; but it's not
relevant to Unix.  Unix programming has a history of relying on the
filesystem to take care of things that other systems handle as special
cases -- devices, for example.  The idea that devices can be files but
TCP/IP sockets cannot runs counter to all Unix experience.

The reason why I continue this discussion here, in comp.std.unix, is
that many Unix programmers hope that the people in the standardization
committees have learned from the out-of-filesystem mistake, and will
rectify it.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 89

Standards Update, IEEE 1003.4: Real-time Extensions

#494

Author: David Vinayak Wallace
Date: Sat, 08 Sep 1990 00:08

20 lines
1389 bytes

From: gumby@Cygnus.COM (David Vinayak Wallace)

   Date: 7 Sep 90 15:23:19 GMT
   From: chip@tct.uucp (Chip Salzenberg)
[Most of quoted message deleted.  -mod]

   It is true that other operating systems get along without devices,
   IPC, etc. in their filesystems.  That's fine for them; but it's not
   relevant to Unix.  Unix programming has a history of relying on the
   filesystem to take care of things that other systems handle as special
   cases -- devices, for example....

What defineds `true Unix?'  Don't forget that Multics had all this and
more in the filesystem; this stuff was REMOVED when Unix was written.
Is this `continued development by the creators of Unix' just going
back to what Unix rejected 20 years ago?

Or for a pun for Multics fans: what goes around comes around...

Volume-Number: Volume 21, Number 92

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#497

Author: Peter da Silva
Date: Sat, 08 Sep 1990 15:27

17 lines
1419 bytes

From: peter@ficc.ferranti.com (Peter da Silva)

Other operating systems have learned from UNIX in this respect, in fact!

AmigaOS puts all manner of interesting things in the file name space,
including pipes (PIPE:name), windows (CON:Left/Top/Width/Height/Title/Flags),
and the environment (ENV:varname). Other things have been left out but are
being filled in by users (it's relatively easy to wite device handlers on
AmigaOS). There are some really odd things like PATH:. This can be opened
as a file and looks like a list of directory names, or used as a directory
in which case it looks like the concatenation of all the named directories.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

Volume-Number: Volume 21, Number 93

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#517

Author: Martin Fouts
Date: Mon, 17 Sep 1990 21:02

84 lines
4549 bytes

Submitted-by: fouts@bozeman.bozeman.ingr (Martin Fouts)

>>>>> On 7 Sep 90 15:23:19 GMT, chip@tct.uucp (Chip Salzenberg) said:

Chip> According to fouts@bozeman.bozeman.ingr (Martin Fouts):
>I'm not sure which Unix you've been running for the past five or more
>years, but a lot of stuff doesn't live in the file system name space ...

Chip> The absense of sockets (except UNIX domain), System V IPC, etc. from
Chip> the file system is, in the opinion of many, a bug.  It is a result of
Chip> Unix being extended by people who do not understand Unix.
                             ^-------------------------------^

My aren't we superior.  (;-) At one time, I believed that sockets
belonged in the filesystem name space.  I spent a long time arguing
this point with members of the networking community before they
convinced me that certain transient objects do not belong in that name
space.  (See below)

Chip> Research Unix, which is the result of continued development by the
Chip> creators of Unix, did not take things out of the filesystem.  To the
Chip> contrary, it put *more* things there, including processes (via the
Chip> /proc pseudo-directory).

The value of proc in the file system are debatable.  Certain debugging
tools are easier to hang on an fcntl certain others are not.  However, the
presences of the proc file system is not a strong arguement for the
inclusion of othere features in the file system.

Chip> It is true that other operating systems get along without devices,
Chip> IPC, etc. in their filesystems.  That's fine for them; but it's not
Chip> relevant to Unix.  Unix programming has a history of relying on the
Chip> filesystem to take care of things that other systems handle as special
Chip> cases -- devices, for example.  The idea that devices can be files but
Chip> TCP/IP sockets cannot runs counter to all Unix experience.

Unix programming has a history of using the filesystem for some things
and not using it for others.  For example, I can demonstrate a
semantic under which it is possible to put the time of day clock into
the file system and reference it by opening the i.e. /dev/timeofday
file.  Each time I read from that file, I would get the current time.
Via fcntls, I could extend this to handle timer functions.  It wasn't
done in Unix.  (I've done similar things in other OSs I've designed,
though.)

The whole point of the response which you partially quoted was to
remind the poster I was responding to that not all functions which
might have been placed in the filesystem automatically have.

Chip> The reason why I continue this discussion here, in comp.std.unix, is
Chip> that many Unix programmers hope that the people in the standardization
Chip> committees have learned from the out-of-filesystem mistake, and will
Chip> rectify it.
Chip> --

The reason I respond is that it is not automatically safe to assume
that something belongs in the file system because something else is
already there.  There is also an explicit problem not mentioned in
this discussion which is the distinction between filesystem name space
and filesystem semantics.  Sometimes there are objects which would be
reasonable to treat with filesystem semantics for which there is no
reasonable mechanism for introducing them into the filesystem name
space.  Because of the way network connections are made, I have been
convinced by networking experts (who are familiar with the "Unix
style") that the filesystem namespace does not have a good semantic
match for the network name space.
 
Chip> Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>

Chip> Volume-Number: Volume 21, Number 89

Marty
--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd!fouts@ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa

Volume-Number: Volume 21, Number 114

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#530

Author: Peter da Silva
Date: Sun, 23 Sep 1990 15:48

42 lines
2395 bytes

Submitted-by: peter@ficc.ferranti.com (Peter da Silva)

In article <523@usenix.ORG> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
> My aren't we superior.  (;-) At one time, I believed that sockets
> belonged in the filesystem name space.  I spent a long time arguing
> this point with members of the networking community before they
> convinced me that certain transient objects do not belong in that name
> space.  (See below)

You mean things that don't operate like a single bidirectional stream, like
pipes? It's funny that the sockets that *do* behave that way are not in the
file system, while UNIX-domain sockets (which have two ends on the local box)
are.

> Unix programming has a history of using the filesystem for some things
> and not using it for others.

UNIX programming has a history of using whatever ad-hoc hacks were needed
to get things working. It's full of evolutionary dead-ends... some of which
have been discarded (multiplexed files) and some of which have been patched
up and overloaded (file protection bits). But where things have moved closer
to the underlying principles (everything is a file, for example) it's become
the better for it.

> Sometimes there are objects which would be
> reasonable to treat with filesystem semantics for which there is no
> reasonable mechanism for introducing them into the filesystem name
> space.

This seems reasonable, but the rest is a pure argument from authority.
Could you repeat these arguments for the benefit of hose of us who don't
have the good fortune to know these networking experts you speak of?

[ Everyone involved in this discussion, please try to keep it in a
technical, not a personal, vein.  -mod ]

-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

Volume-Number: Volume 21, Number 127

🚀 go-pugleaf

Thread View: comp.std.unix

Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Re: Standards Update, IEEE 1003.4: Real-time Extensions

Thread Navigation