Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!darrell
From: darrell@sdcsvax.UUCP
Newsgroups: mod.os
Subject: Re: kernel servers vs. user servers.
Message-ID: <2478@sdcsvax.UCSD.EDU>
Date: Sat, 17-Jan-87 13:42:42 EST
Article-I.D.: sdcsvax.2478
Posted: Sat Jan 17 13:42:42 1987
Date-Received: Sat, 17-Jan-87 23:49:37 EST
Organization: University of California, San Diego
Lines: 60
Approved: mod-os@sdcsvax.uucp

--

> File servers are not something that every user can write, but I certainly
> want the flexibility of having various gurus and researchers being able to
> write new file servers whenever they want to.    Writing a file server is
> a fair amount of work, but is not unreasonable for a Master's thesis.

I agree.  My point is that, apart from some significant-but-secondary
issues of debugging, this is independent of whether file servers are part
of the kernel or not.  Kernels with multiple file systems are not uncommon
now, and there is no intrinsic reason why an experimental file system cannot
coexist with a production one in such a kernel.  (It is shameful that UCB
did not do this with 4.2, in fact, since the 4.1->4.2 filesystem conversion
was an ideal application for it.)

It is certainly true that changing and debugging file systems is easier and
(on a multi-user machine) safer when they are not part of the kernel.

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry


--

> - Testing and debugging a new, improved, better and faster (and,
> therefore, completely unreliable:-) server can be done during
> normal production time, and all normal debugging tools are available.

True.  On the other hand, presumably one does not test/debug a file server
all that often...

> - Backward compatability or emulation of a different OS is much easier.

Not really; there is no fundamental difference between kernel and user
file servers in this regard that I can see.  (Remember that kernels can
have more than one kind of file system, with kernel code implementing all
of them.)  Can you elaborate?

> - By splitting a service into smaller services these services become
> much easier to understand (and, hopefully, robust).

Yes, but this is largely orthogonal to the issue.  It is perfectly possible
to have a kernel file system which is split cleanly from the rest of the
kernel (although admittedly a separate address space adds to the firmness
of the split).  Kernels which support multiple different file systems go
in for this to a considerable extent, of necessity.  Equally, it is possible
to have user-level file servers whose interface to the kernel is messy and
complex and whose innards are complicated and incomprehensible.  Moving a
service across the kernel-user boundary is neither necessary nor sufficient
for clean partitioning, although it may encourage it.


Understand, I am in favor of user-level file servers, subject to some
reservations about performance.  But I see them as a modest win if done
right, rather than an automatic huge win.


				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry
--