From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.os.research
Subject: Re: On debugging (was Re: Microkernel for Real-Time Computing)
Date: 23 Dec 92 01:51:21 GMT
Organization: Prifysgol Cymru, Aberystwyth
NNTP-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@ftp

Tage Stabell-kuloe writes:

  [ .. micro kernelization helps as putting each separate bit of
  functionality is a separate address space helps with catching
  errorneous memory references ... ]

Tage> There is no such thing as a free lunch.  It is more expensive for
Tage> one service in the kernel to [insert your favourite IPC mechanism
Tage> here] in order to inform another part of some event, then just
Tage> jumping to it.

The cost can be very much reduced. I have proposed ten years ago having
threads that can switch address spaces, so that each address space
becomes a protected procedure (a la CAP or PDP-1, or more recently
Richester's Elmwood or Psyche), that can have a variable number of
threads (from zero to N) running in it.

So for example each device driver, file system type, cache manager could
be a different address space, and (both kernel and user) threads can
switch address space to access each module's code and state.

The cost of doing so is amazingly small even on stock processors (wait
about one year for my dissertation to complete :->). All you do
essentially is, on many architectures, change the pointer to the page
tables.

Then this becomes quite true:

On 15 Dec 92 20:41:53 GMT, peter@ferranti.com (peter da silva) commented:

peter> Sure, but if you simultaneously speed up IPC (like, by making the
peter> kernel small enough to fit in the on-chip cache) then everything
peter> in the system becomes faster. If you speed up IPC enough, it
peter> becomes lost in the noise.

Since one can use exactly the same mechanism described above for
kernel-kernel, user-kernel, user-user address space communications, then
one get even a speed up.

Even kernels that copy things around a bit (starting with Thoth) or that
do copy-on-writing have been shown to have low enough IPC costs.

If anybody from QNX is reading, I guess they will take the opportunity
to boast about how low have become their overheads with release 4.0 (and
I think they were low enough already).n

Only if you do it very innocently on totally unsuitable hardware
(Berkeley's venerable capability OS for CDC's mainframes) things are
bleak.

peter> Personally, I think the ideal solution would be to provide a
peter> binary interface to the kernel that reains the same whether
peter> you're running in the kernel address space or not,

Indeed, indeed. This is particularly easy if one uses doubly indirect
pointers to address space entry points, much as Mach does for ports.

peter> so moving things into and out of the kernel simply becomes a
peter> matter of performance tuning.

Actually you never need move anything in the 'kernel'; the kernel just
maintains the entry point capabilities, and does address space
switching, not even task switching (well, in theory). Everything else is
in some address space. Some address spaces are given privilege to access
hw resources (e.g. drivers, the real memory allocator), but that's all.

There have been a few systems like this in the past, for example KeyKOS
(the scheduler(s) can be user code, which is one up on Mach or TWENEX,
where only the pager(s) can be user code)
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta