From: kf8nh@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Linux v. Coherent: Comments Date: Mon, 18 Jan 1993 17:32:31 EST
tzs@carson.u.washington.edu (Tim Smith) writes:
> kf8nh@kf8nh.wariat.org (Brandon S. Allbery) writes:
> >Until relatively recently, Coherent was a clone of *V7* Unix. Needless to
> >say (I do hope! --Perhaps V7 is unknown to anyone except us old fogies
> >nowadays) most modern programs require features missing from that ancient
> >system.
>
> What was missing from V7 that a modern program would require, and that could not
> be done with device drivers?
Rephrase that slightly, adding "compatibly", and maybe you'll see the idea.
I don't deny that a kernel hacker who was intimately familiar with the
kernel source code could whack up something to do almost anything --- but I
have doubts about his managing to make the C interface look like either BSD
or System V without having it fall apart completely on non-textbook cases.
Sockets: a device driver implementation would not be very compatible, or
would have too many restrictions.
Generalized select(): ugh. I suppose you could write a device driver to
watch the clists for a tty device, but how about combining this with both
sockets (the original reason for select()) and a timeout, so you can run all
those BSD programs? You would have to implement select() itself as a device
driver which takes a list of file descriptors, determined if they were on a
tty device or a socket pseudodevice (as above) or a filesystem pipe
(remember, this is V7 we are talking about, pipes are filesystem pipes, NOT
socketpairs!), etc., and watched them all, either blocking or timeout or
polled (the latter is the easiest but probably the least common case).
Remember that the V7 kernel didn't have any support built into it for this,
unless you count that buggy mpx(2) stuff.
Shared memory. Can you *really* claim to do this with a *device driver*???
Job control. The basics are of course taken from the process trace
mechanism, but you need to manage multiple process groups.
Remember, I said *compatibly*. You can do almost anything by twisting a
device driver into strange contortions that cause it to translate writes
into modifications of the system process table, etc., but you will need
similar contortions in the user code --- and even if you can manage that, by
the time you've added all the pseudodevices you need you are going to
discover that V7 couldn't handle all that many open files per process so you
can't use all this stuff anyway. Kinda makes it difficult to drop existing
BSD or System V code on top of your hacks.
++Brandon