Re: LINUX is obsolete
[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