mod-os@sdcsvax.uucp (01/02/87)
From: Darrell Long (The Moderator) <mod-os@sdcsvax.uucp>
Operating Systems Digest Thu Jan 1 19:41:22 PST 1987 Volume 1 : Issue 0
Today's topics: The Re-birth of MOD.OS
----------------------------------------------------------------------
Greetings. Welcome to MOD.OS. My name is Darrell Long
(Darrell%beowulf@sdcsvax.uucp), and I will be moderating this
newsgroup. I will collect submissions and publish them periodi-
cally (every few days) as a digest.
My goal with this newsgroup is to provide a medium of exchange
among folks interested in operating systems. My personal interest
is in operating systems research, distributed systems in particu-
lar. I think that this newsgroup can be a valuable way to ex-
change technical information is a timely manner; certainly much
quicker than in the archival literature.
So, please, take time to participate! There are so many in-
teresting things going on in operating systems research. There
are many new and interesting systems that few people hear about
(yes, Virginia, there is life after UNIX) -- MACH, the V Kernel,
Clouds, Amoeba, Cronus, just to mention a few.
Researchers: Please use this newsgroup to distribute abstracts of
your latest publications and technical reports. This will give a
wider audience to your work, and increase the interest in your
system.
I am just the moderator, it is you who will make or break this
newsgroup. Please submit items of interest -- in any area of
operating systems (but let us leave the arguments of how many ar-
guments cat(1) should have to another group).
Here are some possible topics for discussion (grab one and run
with it):
1. Should file servers be state-less as they are in SUN's
NFS?
2. Should more functionality be moved into the operating
system kernel, or should it be provided by user-state
servers?
3. Should transactions be provided by the operating sys-
tem, or should they be, as Prof. Stonebraker suggests,
left to the database implementor?
4. Should the file system be integrated with virtual
memory? (Shades of Multics!)
5. Should the IPC be part of the file system, as it is in
Sprite?
------------------------------
End of Operating Systems Digest
*******************************mod-os@sdcsvax.UUCP (01/09/87)
-- > Here are some possible topics for discussion (grab one and run > with it): Herewith some comments on a few of them: > 2. Should more functionality be moved into the operating > system kernel, or should it be provided by user-state > servers? Alternatively, does it matter? It's all very well to say that your file system is in a user-state server rather than in your kernel, but your users are probably just as dependent on every little detail being right. To make user-state servers more than an irrelevant implementation detail, the user must be offered a choice of servers AND IT MUST BE EASY TO WRITE A SERVER! Or at least, not impossibly hard. If writing a server is as touchy a job as writing the equivalent inside the kernel, the wonderful flexibility will get little use. Consider a Unix analogy: there is nothing stopping you from writing your own shell, but very few do. Why? Because writing a shell is difficult, and it's important to get it right. The level of functionality that people are used to getting in a shell is high, and failures are serious trouble. So producing something that people would be willing to use as a shell means getting a large, complex program pretty damn close to 100% right. What's more, there is very little in the way of helpful tools for the job. Neither of the two major shells is split up into library functions etc. in such a way that one could cannibalize it easily; in fact, both have a reputation for obscure and cryptic code. (The Korn shell is said to be rather better in this respect, but it is much less widely available.) There have been a few alternate shells built, but it's a big project and not worth doing unless something really radical is involved. A vaguely similar situation is found in provably-secure-kernel projects. As I understand it, moving functionality out into "trusted processes" is not given nearly as much emphasis as it once was, because a verified kernel that is vitally dependent on unverified processes for its security is not really a very interesting object. > 3. Should transactions be provided by the operating sys- > tem, or should they be, as Prof. Stonebraker suggests, > left to the database implementor? Speaking as a kernel implementor rather than as a transaction user, they should be provided by the operating system when, and only when, the database community can agree on a common functionality that is not overly complex to specify or implement. I see no indications of such consensus. Given the lack of consensus on the rather simpler questions of locking, I'm not about to hold my breath waiting for universal agreement on transactions. As long as the number of different schemes roughly equals the number of investigators in the field, the kernel should provide tools rather than solutions. (Actually it should continue providing tools rather than solutions even if there is consensus, but performance and integrity may push strongly for an in-kernel implementation once everyone agrees on what it should do.) > 4. Should the file system be integrated with virtual > memory? (Shades of Multics!) There are people who swear by this, and there are people who swear at it. I tend toward the latter camp. Implementing things like ttys or pipes as virtual memory gets troublesome unless the size of segments can be given down to the byte, which is seldom the case (certainly it isn't in Multics). Furthermore, integrating files and virtual memory means a very large lump of code is tightly interwoven. The Xerox PARC people tried this, and seem to have judged it a mistake. Their newer system has a much simpler virtual memory scheme which is *not* dependent on complex machinery like the file system; hence virtual memory can be implemented at a very low level and is available as a tool in the implementation of almost everything else, notably the file system. They say this is a clear win. I am inclined to believe it. [Maybe we should consider pagers which are user specifiable such in MACH -DL] > 5. Should the IPC be part of the file system, as it is in > Sprite? I don't remember exactly how Sprite does things. Certainly there is a lot to be said for making the IPC name space part of the file system, simply to avoid having two differently-run name spaces for no good reason. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry --