Neal H Walfield wrote:
.> > It sort of says: Microkernel: 386-assembler
> > Servers: C++
>
> I would tend to disagree. What literature have you read? Are you thinking
> along the lines of micro implies small (or size at all)? As that is simply
> not true in the common case (look at Mach, vxWorks, fiasco etc).
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."
Eh, so yes, I thought of the remains as something small and easily
comprehensible. I imagined an initial control flow that sets up data
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 cababilities 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
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.
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 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?
But seriously, 'giving back the data' only means 'passing a pointer
address', doesn't it?
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?
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?
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!
Greetings, Atle
PS Am I the only newbie on the list?
And, I saw some people speaking about Berlin, X, ... what happened to
NeXT? That was so-o-o brilliant ...
ENDPS
