Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/12/84; site mit-prep.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!mit-hermes!mit-prep!x
From: x@mit-prep.ARPA (Dean Elsner)
Newsgroups: net.micro.amiga,net.micro.atari,net.micro.mac,net.micro.68k
Subject: Re: A 'generic 68K OS' needed
Message-ID: <10@mit-prep.ARPA>
Date: Fri, 28-Feb-86 18:03:27 EST
Article-I.D.: mit-prep.10
Posted: Fri Feb 28 18:03:27 1986
Date-Received: Sun, 2-Mar-86 19:01:16 EST
Organization: The MIT AI Lab, Cambridge, MA
Lines: 61
Xref: watmath net.micro.amiga:2200 net.micro.atari:2942 net.micro.mac:4937 net.micro.68k:1535

Bias:	I *LIKE* inter alia RSX-11. I realise I may be the last person in
	North America to do so.

Idea:	Could O/S hackers please make the file system detachable from the
	rest of the O/S? This requires treating file systems like they
	existed at the other end of a network, and doing remote procedure
	calls like "create a directory entry for file X and give it name Y".

	An immediate benefit of this is that when you plug a FOO-format
	diskette (or binary file) into a BAR-machine all your ordinary
	utilities keep working but they use a different name for the
	diskette drive in order to use a different file-system server.

More:	To do this, you distinguish between a "device-driver" which hides
	those details of hardware to horrible for ordinary mortals to
	behold and a "file-system" which assigns meanings to the bit
	ingested and egested by the device-driver. Not only is this
	wonderfully useful for disk file systems (eg using Un*x utilities
	to help manipulate CP/M disks) but the same idea fits very well
	with terminals. You use a "crt server" to do such things as
	"scroll window" and this is converted into messages for a "device
	driver" which tickles the screen to acheive the task.

EG:	DEC (perhaps to protect some marketroid's career by inventing one
	more artificially distinct product) sells different flavors of
	files-11 on different (PDP-11 based) boxes. I recently moved a
	lot of my file utilities (written in C) from an RSX box (where
	I had to use numbered, non-heirachical directories) to another
	PDP-11 in a terminal, which had named, heirachical directories.
	All my programs worked 1st time on these new directories & file
	names. By the way, I *ONLY TRANSFERED THE BINARIES*. No compilation
	was needed to let the programs work with a 'new' file system. I
	also moved some utilities (for which I had no sources) and they
	worked 1st time too.

Refer:	RSX-11 has "Ancillary Control Process"s (ACPs) for file systems. They
	mix and match with "Device Drivers" which bend the bits. (I know
	about "class drivers" Virginia, but this is complex enough without
	recursion, reliability etc issues!) Likewise they have "ACD"s for
	terminals. Since Vaxen are ubiquitous (and often more 'respectable'
	you might want to read about ACPs (same concept) on vaxen.

I realise that the usual "Un*x is good enough, don't force users to learn
more concepts that they need" argument applies. I suggest that the discipline
of embedding remote proceedure calls into your operating system (just so it
can survive the '80s) will both help you to better organise the un*x concepts
and may allow you to flush certain concepts that become redundant as other
concepts are generalised for a network environment.

If you don't think the "un*x concepts are good enough" argument applies,
I could be persuaded to post a similar rave about why I think embedded
delimiters in files (eg '\n' in un*x) are a lose. My counter-examples
would be based on files-11 (because so many people have access to it) but I
got the idea from CDC 60-bit machines and refined it making pdp-11s emulate
IBM mainframes (faster that real time!!).

I trust (of course) all you O/S hackers will distribute source code to the
net. This will give users enough confidence that *someone* near them will
maintain the O/S that they will be happier to commit to the O/S.
-- 
x@prep.ai.mit.edu Disclaimer: I am not me.