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

Text File | 1992-07-21 | 3.7 KB | 80 lines

Newsgroups: comp.os.minix
Path: sparky!uunet!mcsun!sun4nl!relay.philips.nl!philce!meulenbr
From: [e-mail] (Frans Meulenbroeks)
Subject: Re: Microkernel discussion
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET post news)
Organization: Philips Consumer Electronics, Eindhoven
References: <[e-mail]>
Date: Tue, 21 Jul 1992 13:59:17 GMT
Lines: 68

[e-mail] (Adrie Koolen) writes:

>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.

Ok. I get your point. I can imagine the following mechanism:
Interfacing between a process and the kernel is done through a limited
number of functions. In my view the interface always was done through
message passing. If these functions are defined in a separate file
(e.g. utility.c), then I see no real problem in directly calling
kernel routines in systems where this is possible. This would simply
mean a different file utility.c on different systems.
I see an advantage in this approach.

>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.

Not in my prototype. All needed information is passed through messages.

[... lots trimmed ...]

>>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.

Well, determining which process is registered under the string "WINI"
will require a table search, which is costly if it has to be done
on every message send.
There is a substantial performance gain inquiring only once and saving
the result (and be able to use the address in several sends).

Also the situation where a driver dies is quite rare (but of course it
can occur). For the time being I decided just to ignore this case.

In due time this could be solved by redefining the address to which
the data is sent. I can imagine that the address consists of e.g.
proc no. + pid or proc no + name, and that send checks if the
address is still valid. If not an error could be returned, and the
caller can check if there is another new process registered under that
name and rework the address.
Undoubtly other/better solutions for this problem exist.

--
Frans Meulenbroeks        Philips Research Laboratories
preferred email address:     [e-mail]