Re: [OT] Interview with Con Kolivas on Linux failures
Andrew Sackville-West wrote:
[snip]
The modularity has some positives: a failure in one module will
not bring down the whole system. of course this is pretty rare in
linux these days too, but is certainly possible. It also provides some
serious security bonuses because a security failure in one
user-inserted module does not mean that the rest of the system is
compromised they way would be in the monolithic kernel model. I guess
some of these ideas are working their way into linux with the
inclusion of user-space drivers.
What you list as advantages of the microkernel approach are not
all obvious to me. All kernel services should be necessary
services. One doesn't want to move apps into kernel space.[*]
So, even with microkernel architecture, a failure in a kernel
level module which leaves the microkernel "up" still results
in a serious system failure. Recovery in such a circumstance
seems unlikely to me. I suppose that there might be some
kernel services which could be restarted, something like a
demon is today, but I have not seen any literature on this,
and it seems, as I said, unlikely. If it were so, then I'd
cast a very jaundiced eye on the decision to make a certain
module be part of the kernel. Maybe it should be a demon or
driver.
OTOH, one serious lack (IMO) with Linux is that drivers cannot
be started, stopped, uninstalled, and installed on a running
system. LynxOS supported that, and I found it to be wonderful
to be able to make changes to a driver, stop the existing one,
uninstall it, and install the changed one without having to
reboot all the time. The biggest advantage, though, was being
able to have the drivers come up, look for hardware, and if
it wasn't present, then just leave, but later be able to install
if necessary without rebooting.
I am not an expert in microkernel architecture.
There are also negatives: there is overhead in the communication
between the modules that might not be there in the monolithic
model. And, I suppose, having the system remain up when all the
I have certainly read literature to this effect.
modules for the input methods go down is only of minor convenience,
but I really don't know what I'm talking about here.
:-)
[snip]
A parallel conversation on /. (I know i know, its an addiction) was
discussing implementation of different lines for MS again, splitting
between a desktop-user oriented release and a more stable business
release. Who knows what that all means, but its an intriguing parallel
to the ck situation. He wanted a better desktop while linux is
pushing for more server oriented priorities. Maybe Hurd can actually
work out for both parties by simple implementation of different
low-level modules: one set of scheduler/IO/"interactivity" modules for
desktop versus another set for various server funcitons, or heavy
computing uses, whatever. Even better would be a kernel that could
switch modes on the fly based on what sorts of tasks were running at
the time...
Umm, you seem to have the impression that there are scheduling
algorithms which are "good for desktop apps and bad for other
types of apps" and scheduling algorithms which are "good for
server apps, but bad for desktop or other apps". The truth is that there
are predictable algorithms which give guaranteed results, but
require tuning to get the results you want, including assigning
what priorities are required by each app, and there are ad-hoc
scheduling algorithms which try to give time to apps based on
what kind of app they are. The former results in somewhat difficult
to tune systems which give predictable performance. The latter
gives systems which seem easier to tune because they mostly
work acceptably, but which are actually impossible to tune to get any
kind of guaranteed behavior.
IOW, the former requires the user to characterize his needs, but
then guarantees that those needs get met (or fails to, and lets
you know if it doesn't have enough resources), the latter tries to
guess what the user needs, and when it fails gives the user no recourse.
The former also requires that apps be written to realize that,
just because they are necessary, they shouldn't just run forever
without either blocking or yielding. If they have latency requirements,
then they need high priority, but shouldn't hog the CPU.
BTW, not all real time scheduling algorithms are priority
preemptive, and there is active research going on in RTOS scheduling,
but nearly all use priority preemptive along with Rate Monotonic
Scheduling analysis used to set the priorities. Other means for
determining the priorities for priority preemptive than RMS may be used,
of course. Also, there are various policies regarding how events
out of control of the scheduler get handled (like interrupts).
When multithreaded apps enter in, then a whole host of other
considerations come into effect, not least of which is whether
a thread is considered a kernel managed object, or the kernel
manages only processes, and they do internal thread management.
This is a significant difference in approach, and the two are
not very compatible, and there is a lot more debate than
agreement about this decision. Delivery of signals to multithreaded
apps is also very much an object of research.
AIUI, the scheduler in Linux is integrated (someone correct me
if I'm wrong) but supports more than one policy. My machine reports
this:
$ apropos scheduler
gpilot-install-file (1) - gnome-pilot file conduit scheduler
sched_getscheduler [sched_setscheduler] (2) - set and get scheduling
algorithm/parameters
sched_setscheduler (2) - set and get scheduling algorithm/parameters
I am not a Linux scheduler expert.
[*] Except for Internet Explorer, of course.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply to: