Seeking a Development Environment (Sun?)

[Guy Harris]

(Comments on statements in the original article, rather than on the reply,
are in parentheses.  We haven't received the original article yet; USENET is
a datagram service, which is why the "notes" idea of linking related
articles together, while a nice idea, is not a panacea.)

> >Other things such as much of the network hanging
> >when a server node goes down until you edit fstab and reboot really bothers
> >me.  
> 
> Why did you have to edit fstab, unless to bring up a replacement
> file server? I suppose you would have to if you wanted to
> have another server provide the /usr/bin /bin and /ucb/bin directories.
> Or the swapping partitions (this is ND, not NFS by the way).

If you're getting most of your programs (/bin, /usr/bin, etc.), a diskless
machine will probably not be very happy if the server goes down, unless 1)
it has a huge (directory entry, inode, disk block) cache, has all the data
it needs locally, and doesn't time out entries in the cache, or 2) can
automatically switch to a backup server, regardless of what OS it's running.

If he's talking about other file systems he's mounted, he can mount them
"soft", in which case attempts to access those file systems when the system
supplying is down will time out rather than retrying until the server
responds.  You pays your money and you takes your choice:

	You can get "guaranteed" service from a server, in the sense that
	the client will continue indefinitely to retry requests; however,
	this means all processes on whose behalf those requests are made
	will hang until the server comes back up.

Or

	You can tell the client to give up after some number of retries,
	so that it won't hang indefinitely; however, this means any
	process trying to access a file on a dead server will get I/O
	errors.

(In SunOS 3.2, you can turn on the "interruptible I/O" flag for hard mounts;
in this case, you can, at least, abort the program trying to access that
file.)

> >You can get NFS for the Apollo
> 
> I have heard from some Apollo people that they will NEVER support NFS.
> Also, I believe they have demonstrated some limited type of NFS remote
> mount, but this is not the same thing.

What Apollo has is client routines that plug into their system using their
object-oriented file system, coupled with server processes that run (In user
mode, I believe) on other machines.  As far as I know, they do not use NFS
protocols for this.

> > but I don't believe that Apollo wants
> >to release it...

(I was a bit confused by his comment here; if Apollo hasn't released this
alleged NFS implementation, how can you get it?)

> Re: File locking. I would suppose that NFS file locking will be added 
> eventually.

"Fixed in 3.2".  The record locking "fcntl" calls that appeared in System V,
Release 2, Version X (for some value of X dependent on which machine you're
talking about) are supported, as well as the "/usr/group" "lockf" routine
built on top of them.

> But I have a dumb question. Unix didn't have file locking
> for years, yet people got around it by either creating another `lock'
> file and testing for the existance of it, or by using a specialized 
> device driver to provide synchronization of different processes.
> Why is file locking the BIG DEAL? It seems to me that all of the vendors
> who have their own proprietary scheme knock NFS because of this, yet
> Unix has been lacking in the `niceties' of file locking for years.
> Is this just Sour grapes?

If you are frequently locking and unlocking objects, the use of a lock file
does hurt performance.  (FYI: unless you have the 3-argument "open" that
first appeared in S3, and was picked up by 4.2BSD, you should not use file
creation as a locking mechanism unless processes running with super-user
privileges don't have to do locking.  Traditionally, it was done by creating
a lock file and making links to that file in order to lock something.)
Adding a special lock device driver is not conceptually any different from
adding a special lock system call; the only difference is the way the
locking code plugs into the system.

> >Still, every modual of the SunOS has been modified.  From Sunwindows
> >to Yellow pages, the operating system is different than bsd.

(Well, yeah; for one thing, it has to run on machines that aren't VAXes.  For
another, if you want to put something like NFS into the system in a clean
way, you do have to reorganize the system code quite a bit.  And as for
SunWindows, the kernel changes for it are mostly additions, rather than
changes; would you rather not have a window system?

This is only completely true in the trivial sense; yes, we did add our own
SCCS headers to every UNIX source module.  Lots of source modules, even in
the kernel, are essentially unchanged.)

> You cannot buy a board that comes with a Unix device driver and install it
> in an Apollo.

To be fair, you can't necessarily do this with a Sun, either.  The notion of
a portable device driver is about as valid as the notion of a portable
kernel or a portable C compiler; yes, a lot of the code goes over without
much change, but when you have to deal directly with the hardware you have
to replace a lot of code with your own code.

> The data structures (as normally documented in /usr/include) are not
> the same.  This is useful, not only with device drivers, but with programs
> like ps(1) that read the internals of the system memory (using /dev/kmem)
> to find out what is going on inside. I have taken courses on the internals
> of Unix, and programs that examine the file system, user areas, etc.
> ARE useful. I would guess that the public domain program `top' won't
> run on an Apollo very easily.

Again, to be fair, nothing is "documented" in "/usr/include".  There is no
published interface to the system internals; they are subject to change
without notice.  Yes, those programs are useful, but there is no reason to
guarantee that they will work without change in all releases of an OS.
Sometimes the cost of not changing a system data structure far outweighs any
possible benefits leaving it alone could bring.

> They even provide programs that make it easier to debug (like adbgen).

(Plug warning) Or "kadb", in 3.2.

> >Prices of the two systems are about the same.  With Apollo, you don't
> >need the server (I run every other node diskless with very good results).
> 
> Are you saying that Sun's need a server, while Apollo's don't?
> I don't understand.

Perhaps by "every other node", he means that an even-numbered node is both
server and workstation, and an odd-numbered node is a client of node N-1
(you can tell I've been a C programmer for too long, I'm calling the first
node node 0).

You can set up a Sun with a keyboard and monitor as a server, so you can do
the same thing with Suns.  We don't run that way here, and I've never seen
that kind of setup with Apollos, so I can't say how well a Sun server would
work as a workstation compared to an Apollo serving the same dual role, or
how big the administrative burden would be for the users of the two
machines, or how much disk space you'd have to add to the dual-use machines.

> >I understand the SunOS
> >source costs a bundle and even then they don't like to give it out 
> >(havn't checked it out, though).

There is some stuff we don't provide.  Most of the source is available,
although I don't know what our policies are on it.

> >Much of the SunOS is getting propietary
> >so I don't know about it becoming a standard.  Also, they haven't let
> >the IEEE committee for UNIX look at their stuff.  To me, Apollo looks
> >much more open.
> 
> 	This is a very strange comment.

It is not only strange, but uninformed.  There are several people from Sun's
system software group working with the IEEE committee.  We have made joint
proposals with HP on terminal driver and reliable signals issues.  We might
not let them look at our source code, but some of them may work for
vendors that don't have UNIX source licenses, and AT&T wouldn't *let* us let
them look at it.  Does the person who makes this claim have examples of
cases where we *didn't* let the 1003.1 committee look at our stuff?

I'm also curious what his definition of "proprietary" is.  We're not going
to sue somebody who sticks, say, a "getdirentries" system call into their
system based on our manual page.  Arguably one of the biggest changes we've
made to the UNIX internals is the "vnode" architecture for supporting
multiple file system types; we provide this to anybody who buys NFS.

> 	And besides, there is a BIG difference in the
> 	interface to a system and the internal implementation.

AMEN.  The IEEE committee is *not* developing an implementation
specification, it is developing an interface specification.  The gory
details of how some particular feature is provided in some particular system
are not directly relevant to this effort in most cases.  Unfortunately,
given how widely available UNIX source is, a lot of people haven't learned
the difference between an interface and an implementation.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)