NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/os/minix/3735

Internet Message Format | 1992-07-21 | 4.4 KB

Path: sparky!uunet!mcsun!sun4nl!phigate!relay.philips.nl!philica!adrie
From: [e-mail] (Adrie Koolen)
Newsgroups: comp.os.minix
Subject: Re: Microkernel discussion
Message-ID: <[e-mail]>
Date: 21 Jul 92 09:31:45 GMT
Organization: Philips Consumer Electronics, Eindhoven, The Netherlands
Lines: 81

In article <meulenbr.711631843@cstw18> [e-mail] (Frans Meulenbroeks) writes:
>I think that accessing the proc struct directly is not very nice
>either. That way, all drivers must know where certain kernel data
>structures are. This also means drivers have knowledge about the
>internals of the kernel. I don't think I like it.

I understand your dislike (a little) but I can't help to find it a little
bit ridiculous that a device driver shouldn't know about the location of
some kernel information. I agree that it's nice to have all OS parts
completely separated, but it's a trade between execution speed, code
length, code modularity, source maintainability, etc. I'm not saying that
I know where the optimum is. Because soft- and hardware differs, and
people have their own demands and opinions, the optimal point is quite
subjective.

In any case, in order to comunicate with the rest of the system, each
driver (or process) should have some fixed information about the rest
of the system, i.e. tables, addresses and/or interrupt numbers. By
restricting the amount of directly available information, the channels
through which the information, which a driver needs from the kernel or
other parts of the system, travels can be a real bottleneck.

Note that I'm not against a clean separation of the drivers and the
kernel, but if it means that I for instance can't code the floppy
driver anymore to read a track in one revolution or have to code the
driver in a very dirty way, I think we should reconsider. Let's wait

>>Now the interrupt() function. On Minix-Sparc, a first level interrupt
>>handler calls the interrupt service routine. The ISR can of course also
>>call a function in the `module' where the FLIH resides, e.g.
>>interrupt(). On an Intel processor, this is also possible (with a far
>>call). The interrupt() function should then end with a far return.
>
>How does the ISR know the addresses of the function to call?

Use an array of addresses of kernel functions. Some will cosider this
`dirty', but also is the agreement on the message numbers and contents.
Everywhere something is agreed upon, the question remains whether
everyone interprets it the same and will stick to the agreements and
not alter them.

>I cannot call interrupt() in my driver directly, since there is no
>procedure with that name in my namespace. Of course you can work around
>this, but why bother.

You could agree on a number of critical kernel functions (like
interrupt(), panic(), umap(), etc., maybe also the address of the
proc[] array), which are `global kernel' functions.

>Why not let the ISR return with the number of the
>process which needs to be interrupt()-ed, and call interrupt from the
>FLIH? (of course you'll need a default value to state that you do not
>need a call to interrupt()). The only thing you give up with this is
>the ability to do several interrupt() calls within one ISR call.
>However, given the fact that an ISR should take as little time as
>possible, I would consider calling interrupt() twice within an ISR
>as bad programming.

I agree fully with this proposition. Still I want some kernel globals
to be accessible by all drivers. As far as I know, in SunOS loadable
device drivers can also access kernel functions and data.

>I propose to let each process let itself register under a name in the
>kernel, and give processes the ability to inquire what the
>address/message id of a process registered under a certain name is.
>
>e.g. a driver would say
>register("WINI");
>while someone wanting to send a message to the wini driver could ask
>give_address("WINI")

Note that you have to guarantee that the `address' of the driver is
not changed in the meantime (between the give_address() and send()
calls). As drivers might die in the meantime (for whatever reason),
the send() might fail or arrive at the wrong driver. If you want to
send a message to "WINI" then why first ask for its address? Simply
use send("WINI", &msg). If "WINI" doesn't exist (anymore) you'll see
it in the return code.

Adrie Koolen ([e-mail])
Philips Consumer Electronics, Eindhoven, the Netherlands