🚀 go-pugleaf

In article <1992Dec23.212321.26522@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
> In article <id.CG2W.R8A@ferranti.com>, peter@ferranti.com (peter da silva) writes:
> >That's right. The UNIX programming model. The point is that the UNIX API is
> >very high level, and can be modified to provide any capability I've ever
> >heard of without breaking it. There is NO excuse for any new operating
> >system after about 1984 or 85 to use anything lower level. It increases the
> >cost of software design, increases the cost of education and training, and
> >decreases the amount of commonly available high quality software.

> OK, try this. VMS has something called an AST (Asynchronous System Trap) which
> is similar to a user-mode interrupt.

Yes, I'm familiar with it from RMX.  There, at least, unless you're working
in assembler it's something to be used with extreme care lest you trash the
language runtime.

> This may occur at any time: for instance,
> an asynchronous I/O can call an AST routine when the I/O completes. When the
> AST routine completes, control returns to the code that was executing at the
> time the AST occurred. (The analogy in NT is the APC, or Asynchronous
> Procedure Call.)

And in UNIX the analog is a "signal". Now, a signal is a little "safer" than
an AST (at least as under RMX), in that it's guaranteed to run in your task
context.

> Now, much of the run-time stuff in UNIX is non-reentrant.

Much of the *C* run-time in *any* language is non-reentrant, and I would
be surprised if the VMS library was any better. If I get an AST while I'm
in the runtime (say, in the Fortran library in the middle of a formatted
I/O statement) I would expect dire consequences from calling the language
runtime. I have never written an asyncronous signal handler under any
operating system (out of UNIX, RMX, AmigaOS, and RSX-11) where I didn't
have to watch for that sort of thing. In RSX all you can do from an AST,
pretty much, is access memory.

> In particular, the 
> use of errno springs to mind. If the AST (or APC) was introduced into the
> UNIX model,

It's in there.

> how can I use these non-reentrant routines safely in an AST
> routine without screwing things up?

You can't. Can you really do

	WRITE (*,10) AA
 10	FORMAT (1X,80A1)

in an AST under VMS?

> >But the UNIX operating system interface is centered on the file system.

> But that doesn't mean that I can put an ACL on a UNIX operating system object.

A UNIX "operating system object" *is* a file. If the file system supports ACLs
you certainly can. What "operating system objects" are you trying to put an
ACL on?

> >You mean like ulimit?

> Get the process's file size limit.
> Set the process's file size limit.
> Get the maximum possible break value.

All possible in System V.

> NT and VMS people might have a rather more pervasive idea of quotas.
> What are hierarchy quotas?

Limits the disk space used under a node in the file system regardless of
who owns the file.

> >> (1) POSIX 1003.1 does not address the many areas that Win32 does.

> >Where it doesn't it can be trivially extended to do so.

> Including my example above?

Everything you've said so far, yes.

> >> (2) POSIX 1003.1 is not a UNIX API.

> >Yes it is.

> Why? It is similar to the UNIX API you mention,

It is entirely based on, and where possible, identical to the common subset
interface to BSD and System V. Differences are usually resolved in favor of
System V, and there is a small amount of arbitrary innovation.

> but it is also
> available on non-UNIX operating systems. (NT and VMS, for example.)

Which makes it effectively a partial UNIX emulator.

> >So, can I access any arbitrary object that a POSIX program might want to use
> >via the filestore name space? If not, that's awfully short-sighted of
> >Microsoft, because that's the way UNIX is progressing.

> No, because the filestore name space is at the botton of the hierarchy.
> Direct object name space access would require access to non-POSIX routines,
> and that's a no-no.

Why? There is no technical justification for this.

> UNIX might access everything through the filestore, but not all other
> operating systems do.

No, but if there is a common object manager with a name space that can be
mapped into a file system name space, there is no technical justification
for not doing so under the POSIX environment.

> Another example from NT: a file in a file system is
> just an object in the object name space. When a file's pathname is given to
> the object name parser, the parser will parse the pathname down to the file
> system's node, then hand over parsing to the file system's parser.

Oh, so they borrowed something from AmigaDOS. Interesting. Plan 9 does this,
too.

> This
> would allow a file system with completely different syntax to be inserted
> with no trouble. What happens to a filestore oriented operating system
> when a completely different file system is used?

Go read the Plan 9 papers, or get an Amiga. It's not new technology by
any means: AmigaDOS was shipped in 1985, and based on an older operating
system from Cambridge called Tripos (note, not all interesting O/S
design is from the US).
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"