Hi,
> I don't want to be killed by the author for completely misunderstanding
> his book, but:
> Well, I absolutely need to go over this again, but Charles Crowley,
> Operating systems - a design Oriented Approach, speaks about
> 'Micro-kernel Operating Systems': "... the device independent parts of
> the I/O system can be also be moved into a system process. This process
> can communicate with the device drivers with messages. In fact, most of
> the operating system can be moved out of the kernel and into processes."
Mach manages all of the low level device drivers. Additionally, it manages
message passing, process management and memory management (and a few
other things) in the microkernel. Some microkernels do a user land
scheduler etc. There is no formal definition on what a microkernel does
and does not do. Only that it provides a kind of abstration of the hardware
for the operating system. Of course, this is not entirely true either.
> Eh, so yes, I thought of the remains as something small and easily
> comprehensible. I imagined an initial control flow that sets up data
One can wish ;) Remember, micro does not imply small.
> structures as stack values that points to a dispatching point, and when
> these data structures have been set up, I imagined the 'microkernel' as
> a simple dispatcher with the ability to read and write queues (ports).
> This is what I thought of building on until a minimum set of
> capabilities (with some knowledge of the capabilities of the 'system
> processes' (servers?) but I don't know what would have been necessary)
> I also got confused because of the presentation of 'client-server'
> programming, I understood it as application programming in a network, I
> didn't think of it as a 'virtual network' inside the OS. I will read
It is best to think about the message passing paradigm as a network;
In fact, Mach was designed with this in mind. Messages do _not_ have to go
to the same machine; they are sent to a port and the Microkernel worries
about getting the messge to the receiver. For instance, one could,
theoretically, have a single auth server on a hurd cluster. All messages
would go to the auth server and it would respond. And this would ALL be
handled by the micro kernel and be 100% transparent to the application and
99% to the Operating System.
> that book again (and possibly, again). Today, I also got a beautiful
> present from my wife: David E. Culler, Jaswinder Pal Singh with Anoop
> Gupta - Parallel Computer Architecture - a Hardware/Software Approach.
You will not find a lot of information on programming Microkernels as
it has really gone `out of style,' at least in the way the hurd wants to
use it. If you want to learn about programming mach and some of its
concepts, you should try to find:
Programming Under Mach
Boykin et al.
Addison-Wesley
1993
It has been out of print for some years now and primarily covers Mach 2.5
(which has a lot of differences from 3.0 which has few differences from 4.0
which in turn has few differences from gnu/mach).
> If I don't understand microkernels by the time I am finished with these
> two, I will start programming banana-counting applications in COBOL.
>
> >
> > Microkernels provide certain services to the Operating System, ``ie, the real
> > kernel,'' to enforce its policies. In the hurd, we have a multi server
> > operating system sitting on top of, at the moment, the GNU Mach microkernel.
> > The microkernel provides the message passing interface and the thread/task
> > and virtual memory: all non-trivial jobs.
> >>... optimising for 386 ... ..
> > This sounds like a lot of work for not addressing the bottle neck. The
> > real bottle neck in the hurd is the Multi-server part, not the microkernel
> > part, which, is often blamed.
> Thank you for the illustration. I am confident that I have a better view
> of where the shoe hurts now.
> The scenario you depicted, is it general, or does it vary with the
> requests?
It is very general; the whole hurd philosophy is based on putting
everything into user space servers. Imagine accessing a disk... then
try doing a ls -R or something similar. Slow!
>
> It seems obvious that something must be done with this algorithm.
> First of all: Authentication.
> I suppose as soon as a process is authenticated, that only 'privilege
> level' (what is this called in Hurdish?) sort of requests need to be
> authenticated. An already authenticated process should get access to its
> files.
> Of course, who knows what files belong to the process?
Exactly.
> But seriously, 'giving back the data' only means 'passing a pointer
> address', doesn't it?
Well, not exactly, since we are dealing with different address spaces,
we have two options. Copy it from the source task into kernel buffers and
then out to the other applications buffers or use some kind of COW (copy
on write optimization).
This is, of course, more confusing than it sounds. Mach ports are all
uni-directional; This makes a lot of sense one you understand what is
going on.
Definition: Ports have one and only one receiver and one or many senders.
Why? Here is an example. A server listens on an advertised (mach) port.
When it receives a message, it performs a transaction and gets a result.
It can not send back over the original port or everyone listening would
hear the potentially, sensitive data. Therefore, the original message
might have also includes another port with a send right on it. The
server will send the result to the application over the supplied port.
Then, whoever is listening on that port will receive the message. Note:
the receiver is not necessary the thread that made the request. It could
have handed the port and the receive right to another thread or even another
task.
> How often is authentication performed in a 'typical' program that does
> something like this:
>
> FILE *f;
> char b[256];
>
> f = fopen(av[1], "r");
> while (fgets(b, 255, fil))
> printf("%s", b);
> fclose(fil);
>
> I would think that the clib handles fopen() to open() without
> interference ... how many read()'s will there be?
> file size / blocksize for the file in question?
> Are the read calls authenticated?
> Will the read acess a buffer directly, so that memory is only
> transferred once for the read and once to put it in b?
Every time a new block needs to be read from disk, libc will need to
contact the ext2fs translator which is done via messages and, therefore,
implies some authentication. So, how many and how often? Depends on
how much is cached on a read; etc. I have not looked at the implementation.
Others know better than myself.
>
> Is is possible (I guess it is :-) to group system calls into 'logical'
> groups and optimize the steps you drew up for one system call in such a
> way that all the calls in the group get optimized?
> Fx., if one memory-copy can be replaced with exchanging a register value
> (these are the things that speed up stuff), could a whole range of
> system calls benefit from this?
Theoreticaly. Yes. In really comes down to what you are trying to do.
This reminds me, on some level, of the whole IDE vs SCSI protocols.
>
>
> Well, I guess I have to dive back into my books now, and look a the Hurd
> when it comes ...
>
> And once again, thanks for explaining the basic stuff, that is what the
> big picture is made up of!
No problem.
>
> Greetings, Atle
>
> PS Am I the only newbie on the list?
No, but we are on help-hurd and not debian-hurd where most of the `talk'
takes place.
> And, I saw some people speaking about Berlin, X, ... what happened to
> NeXT? That was so-o-o brilliant ...
> ENDPS
>
Regards,
Neal
--
----------------------------------------------------------------------------
Neal Walfield [EMAIL PROTECTED]
UMass Lowell - Fox 1512 Phone: 978-934-5347
Fax: 603-415-3645
Love is the triumph of imagination over intelligence.
-- H. L. Mencken
