🚀 go-pugleaf

[If you don't care about System V, hit 'n' now!]

[If Sequent won't answer technical questions here, then I'll do it for them.
What Sequent needs to do is hire some of their more technically competant and
well-known-on-the-net customers, like the way Encore hired Barry Shein. Maybe
Ron Christian can be enticed away from Fujitsu. :-) :-) :-) Just a JOKE, Ron!]

In article <368@pbseps.UUCP> rdp@pbseps.PacBell.COM (Richard Perlman) writes:
>System V seems to be only half-heartedly implemented.

That's not quite fair. Essentially, the Dynix att universe is a mapping layer
for translating SVR2 semantics into 4.2BSD. A combination of the following
hooks are employed:

- The att universe runtime library (libc.a) remaps a number of calls from SVR2
  into their moral equivalent in BSD 4.2 calls. Sometimes, the bulk of the
  "system call" is handled entirely in the library. An example is the uname(2)
  call. (Note, there is nothing at all wrong with this; the SVID specifically
  allows for it.) In addition, Dynix takes advantage of some of its extended
  facilities; for example shared memory operations are performed through the
  mmap(2) facility.

- A number of new system calls were added for semantics that were beyond the
  reach of library calls, e.g., chown(2), open(2), creat(2), and setuid(2).
  There are also some kernel hooks for signals.

- The notion of conditional symbolic links was added. The conditional symlink
  points one of several ways, with a value in the u table selecting which path
  to follow. Of course, this is how the notion of "universes" is implemented.
  It is a very useful and elegant concept (assuming you consider symlinks a
  good idea at all, which many purists do not), and at one time Pyramid and
  Sequent were jointly trying to convince Sun to adopt support for conditional
  symlinks in NFS. I don't know whatever happened to that.

The weakness of the current Dynix implementation is that *distinctly* SVR2
facilities that cannot be emulated by the 4.2BSD kernel are not available.
For example, the SVR2 flock(2) provides either mandatory or advisory file
locking. The 4.2BSD kernel can perform advisory locks only; hence the Dynix
flock(2) also is only capable of advisory locks. Perhaps the most painful
limitation is termio(7), as observed by Mr. Perlman. The Dynix termio calls
all have the correct structures and ioctl(2) calls of SVR2, and code will
compile correctly. But the distinctly System V capabilities like VMIN, VTIME,
and the useful permutations of IXON/IXANY/IXOFF silently fail to work. I do
not believe named pipes work entirely, either, although they could.

The Dynix implementation does cover a large percentage of the System V utili-
ties. The things I've had the most trouble with are datacomm programs. For
example, when HoneyDanBer UUCP is compiled for System V, it is very aggresive
about using all kinds of SVR2 features; it won't run on Dynix. Of course, if
you configure HDB for 4.2BSD, it compiles and runs on Dynix without a hitch. 
Also non-portable are the distinctly System V utilities like init/getty/login.

Note that I am only commenting about the current Dynix *implementation*; the
*design* is not significantly different from the "merged UNIX" strategy that
Sun Microsystems has been following for some time. Library calls, and kernel
when you have to. What Dynix needs is to be brought up to date; SVR2 was old
news three years ago. Perhaps even smarter would be a brand new symmetric port
of SVR3, and forget Berkeley. I'd bet anyone lunch that that is exactly what
Sequent and Unisys are doing, even as we speak; Unisys presently is offering
only an SVR2 port for their version of the Sequent S27 and S81. 

What is humorous -- to me, anyway -- is that Dynix has the internal implemen-
tation of a merged system, but the external appearance of a Pyramid-style dual
port. (A true dual port has two complete and independent sets of system calls,
amongst other things.) Given all the reasons why *not* to do a dual port, this
seems like more of a marketing decision than an R&D one. I haven't seen the
Harris or Gould dual port systems, so I can't contrast them.

Back to Richard Perlman:
>There are problems with term i/o and some simple things (news) just don't
>work at all.

In article <455@sendai.ann-arbor.mi.us> rich@sendai.UUCP (K. Richard Magill) writes:
>What news?  Oxtrap has been running news for almost 2 years now.

Wrong concept. There is a System V utility called news(1), which has nothing
at all to do with Netnews or Usenet.

But I wouldn't call news(1) a "simple thing." Neither the Dynix version nor
the original SVR2 source works (I tested it myself); it doesn't find any news
files. The problem is news.c does its own read and scan of the /usr/news
directory. Dynix cannot (at least, it better not!) manipulate what a program
gets when it reads a raw directory. And of course, Dynix uses the BSD file-
system, which doesn't look much like a System V filesystem. 

So news.c either has to be fixed to use dirent.h (as it does in SVR3) or con-
verted to read BSD directories. Note that any other machine that uses the BSD
filesystem will have exactly the same problem, including Pyramid and Sun.

<csg>