Re: LINUX is obsolete Linux Inside
[Prev][Next][Index][Thread]

Re: LINUX is obsolete



 In article <1992Feb2.220626.25197@trl.oz.au> aduncan@rhea.trl.OZ.AU (Allan Duncan) writes:
 >From article <1992Jan30.013643.3248@menudo.uh.edu>, by kevin@nuchat.sccsi.com (Kevin Brown):
 > 
 >> The *entire* system call interface in Minix needs to be rethought.  As it
 >> stands right now, the file system is not just a file system, it's also a
 >> system-call server.  That functionality needs to be separated out in order
 >> to facilitate a multiple file system architecture.  Message passing is
 >> probably the right way to go about making the call and waiting for it, but
 >> the message should go to a system call server, not the file system itself.
 >> 
 >> In order to handle all the special caveats of the Unix API, you end up writing
 >> a monolithic "kernel" even if you're using a microkernel base.  You end up
 >> with something called a "server", and an example is the BSD server that runs
 >> under Mach.
 >> 
 >> And, in any case, the message-passing in Minix needs to be completely redone.
 >> As it is, it's a kludge.  I've been giving this some thought, but I haven't
 >> had time to do anything with what I've thought of so far.  Suffice it to say
 >> that the proper way to do message-passing is probably with message ports
 >> (both public and private), with the various visible parts of the operating
 >> system having public message ports.  Chances are, that ends up being the
 >> system call server only, though this will, of course, depend on the goals
 >> of the design.
 > 
 >It gets to sound more and more like Tripos and the Amiga :-)
 
 There's no question that many of my ideas spring from the architecture
 of the Amiga's operating system.  It's pretty impressive to see a
 message-passing, multitasking operating system that operates as fast
 as the Amiga's OS does on hardware that slow.  They did a lot of things
 right.
 
 There are some ideas that, I think, are my own.  Or, at least, that I've
 developed independently.  For example, if you have a message-passing
 system that includes the option to transfer message memory ownership to the
 target process, then it naturally follows that you can globally optimize the
 use of your block cache by making your block cache global with respect
 to *all* filesystems.  The filesystem code requests blocks from the
 block cache manager and tells the block cache manager what device driver
 to call and what parameters to send it when flushing the block.  The block
 cache manager replies with a message that is the size of a block (or, if
 you wish to allocate several at a time, several blocks).  Since
 ownership is transferred as a result of passing the message, the block
 cache manager can allocate the memory itself, optionally flushing as
 many blocks as it needs in order to free up enough to send to the caller.
 The block cache manager is, of course, a user process.  If the filesystem
 code is written right, you can kill the block cache manager in order to
 disable the block cache.  The filesystem will simply do its thing
 unbuffered.  Makes for a slow system, but at least you can do it.  You
 can also change the behavior of the buffer cache by sending control
 messages to the cache manager.  Can you say "tunable parameters"?  :-)
 
 You could also accomplish this with some sort of shared memory, but this
 would require semaphore control of the allocation list.  You'd also have
 to figure out a way to flush bits of the cache when needed (easy to do
 if you're a monolithic kernel, but I'm referring to a microkernel) without
 colliding with another process writing into the block.  Semaphore control
 of the individual blocks as well?
 
 >Allan Duncan	ACSnet	 aduncan@trl.oz
 >(+613) 541 6708	Internet aduncan@trl.oz.au
 >		UUCP	 {uunet,hplabs,ukc}!munnari!trl.oz.au!aduncan
 >Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
 
 				Kevin Brown