Re: [9fans] what about microkernel?
Lorenzo Fernando Bivens de la Fuente
It is a small kernel, though...
Cheers!
On 10/6/07, Andrew Wingorodov <ma...@andr.ru> wrote:
> Is Plan9 has a microkernel architecture?
>
> --
> www.andr.ru
>
>
>
Andrew Wingorodov
joh...@sorosj.hd.free.fr
http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
But I think it's not.
Charles Forsyth
with Plan 9 the adjective is more important than the compound noun,
so it's micro and modular, but not a `microkernel'.
most of the microkernels are (probably) much more
elaborate, and indeed simply much more.
in an apparently under-read paper, it was observed that:
The UNIX kernel is an I/O multiplexer more than
a complete operating system. This is as it should be.
Because of this outlook, many features are
found in most other operating systems that are missing
from the UNIX kernel.
Plan 9 goes further, removing even the storage subsystems
from the kernel, and making it a name-space multiplexor,
as much as (or more than) an IO multiplexor, with its focus
on a single protocol.
Andrew Wingorodov
> Plan 9 goes further, removing even the storage subsystems
> from the kernel, and making it a name-space multiplexor,
that sounds great, but oses has not only storage subsystems
you mean, the all 9 subsystems works through 9P and filesystems,
that safe for kernel? a new filesystem engine is not needed
include into the kernel?
my new little experience with QNX made me a fan of microkernel :)
Plan 9 is very good, very nice job, next and future of IT, respect.
No superusers! Infinite File System! Unified interface off all,
any more, of course a big deal...
But "Can We Make OSes Reliable and Secure" by A.T. expresses
a good (maybe not fresh) ideas, isnt it?
--
www.andr.ru
Charles Forsyth
> that safe for kernel?
the kernel doesn't actually implement all that much, and most complex things
are outside the kernel. the biggest exceptions are networking
and low-level device drivers, but the interface to those is small,
or even tiny. the device drivers aren't that big either.
the network has been in and out of the kernel at different times over the years.
qnx is probably the most reasonable so-called microkernel i've seen described
(but i haven't seen their code).
David Leimbach
It's "open sourced" now, as of a few weeks ago.
Ever looked at the L4 family of microkernels?
LiteStar numnums
"By cosmic rule, as day yields night, so winter summer, war peace, plenty famine. All things change. Air penetrates the lump of myrrh, until the joining bodies die and rise again in smoke called incense."
"Men do not know how that which is drawn in different directions harmonises with itself. The harmonious structure of the world depends upon opposite tension like that of the bow and the lyre."
"This universe, which is the same for all, has not been made by any god or man, but it always has been, is, and will be an ever-living fire, kindling itself by regular measures and going out by regular measures"
-- Heraclitus
ron minnich
> It's "open sourced" now, as of a few weeks ago.
>
> Ever looked at the L4 family of microkernels?
>
yep, I could never get them to build on red hat. My mistake, using red
hat, but ... long story.
ron
erik quanstrom
>>
>> Ever looked at the L4 family of microkernels?
>>
> yep, I could never get them to build on red hat. My mistake, using red
> hat, but ... long story.
after looking at the code, i didn't try to compile it.
the version i looked at was c++ and seemed much more
complicated than the claimed handful of system calls.
- erik
Andrew Wingorodov
> On 10/6/07, Charles Forsyth <for...@terzarima.net> wrote:
>> qnx is probably the most reasonable so-called microkernel
>> i've seen described
>> (but i haven't seen their code).
>
its was realy great news of a few weeks ago, i was squatting
free and openqnx in ORG zones for fork of this project
(if the owner will be wants to close the code again :)
But IMH professonal O, the plan is much better.
After all, IHateThisNotation() :)
> Ever looked at the L4 family of microkernels?
Linux is not interesting
Lots of noise from nowhere
--
www.andr.ru
LiteStar numnums
David Leimbach
David Leimbach
Francisco J Ballesteros
be portable, just their interface. His ukernel was hand tuned for a particular
hw/compiler, afaik.
Charles Forsyth
> trick possible.
one way to pass the time, i suppose.
LiteStar numnums
erik quanstrom
> trick possible.
>
there's nothing wrong with assembly per ce, but i don't follow this logic.
generally speaking, compilers are better than humans at doing instruction
scrabble. and worse, optimal instructions are a function of (at least) the
cpu model, northbridge and memory, as slightly different memory latency
or bandwidth could alter the tradeoff between cycles and code size.
- erik
Eric Van Hensbergen
> > His original Kernel, L3, was written in pure assembly for x86, using every
> > trick possible.
> >
>
> there's nothing wrong with assembly per ce, but i don't follow this logic.
> generally speaking, compilers are better than humans at doing instruction
> scrabble.
Depends on the compiler ;)
Ignoring the C++ (or all-assembly) nonsense, the general point of
L3/L4 seemed to be "do IPC really, really well on whatever platform we
are running on and then build a microkernel around it". That's an
oversimplification, and perhaps at that level of abstraction -- that
was the goal of every microkernel (its just many/any didn't succeed at
that goal).
I've been thinking a lot about this, particularly as we've been diving
deep into tracing performance of our network paths as part of the Blue
Gene work. As of our preliminary results, it would seem that Plan 9
attempts to take the most general approach to things with an emphasis
on keeping everything simple. Unfortunately we end up paying a heavy
price in raw performance (at least in the networking case). It may
well be that "benchmark" performance is irrelevant, but I think its at
least worth reviewing other-OS research from the last 20 years to see
what we can learn. It may be the case that we have cut our
abstractions too high to take advantage of some architectural features
present in modern microprocessors -- it may be that we want to allow
for optimized locking and IPC/queues on particular architectures.
I've heard mention the idea of turning the Plan 9 kernel into a a pure
9p mux and building the system around that -- one wonders how
different we would look from a microkernel environment like L4 then.
I know the Japanese folks talked about their efforts of "porting" Plan
9 on top of L4 at last years IWP9 -- I wonder if they've made any
further progress...
-eric
Francisco J Ballesteros
> I've heard mention the idea of turning the Plan 9 kernel into a a pure
> 9p mux and building the system around that -- one wonders how
This sounds like fun.
erik quanstrom
> deep into tracing performance of our network paths as part of the Blue
> Gene work. As of our preliminary results, it would seem that Plan 9
> attempts to take the most general approach to things with an emphasis
> on keeping everything simple. Unfortunately we end up paying a heavy
> price in raw performance (at least in the networking case).
i have found plan 9 ip networking does not fair well pushing ip networking
at 10gbps, especially tcp, and especially with standard ethernet frames.
i didn't spend enough time this spring with the tcp stack to understand what
it's doing, but i got the impression that it could make the simple case
of receiving packets in order simplier at the expence of misorderd packets.
fwiw, we get much greater performance pushing AoE. so i don't think
that network queues themselves are the problem.
- erik
Charles Forsyth
> abstractions too high to take advantage of some architectural features
> present in modern microprocessors -- it may be that we want to allow
I might draw a different conclusion. As with some peculiar memory subsystems,
botched device interfaces, or 80 core processors, I'd say that perhaps the architectural features are there
to meet the needs of hardware designers and are not actually designed to run the programs
people are actually writing. Perhaps someone told them the software people wanted
some of this stuff, but I've got my doubts!
David Leimbach
On 10/8/07, erik quanstrom <quan...@coraid.com> wrote:
> > His original Kernel, L3, was written in pure assembly for x86, using every
> > trick possible.
> >
>
> there's nothing wrong with assembly per ce, but i don't follow this logic.
> generally speaking, compilers are better than humans at doing instruction
> scrabble.
Depends on the compiler ;)
Ignoring the C++ (or all-assembly) nonsense, the general point of
L3/L4 seemed to be "do IPC really, really well on whatever platform we
are running on and then build a microkernel around it". That's an
oversimplification, and perhaps at that level of abstraction -- that
was the goal of every microkernel (its just many/any didn't succeed at
that goal).
I've been thinking a lot about this, particularly as we've been diving
deep into tracing performance of our network paths as part of the Blue
Gene work. As of our preliminary results, it would seem that Plan 9
attempts to take the most general approach to things with an emphasis
on keeping everything simple. Unfortunately we end up paying a heavy
price in raw performance (at least in the networking case). It may
well be that "benchmark" performance is irrelevant, but I think its at
least worth reviewing other-OS research from the last 20 years to see
what we can learn. It may be the case that we have cut our
abstractions too high to take advantage of some architectural features
present in modern microprocessors -- it may be that we want to allow
for optimized locking and IPC/queues on particular architectures.
I've heard mention the idea of turning the Plan 9 kernel into a a pure
9p mux and building the system around that -- one wonders how
different we would look from a microkernel environment like L4 then.
I know the Japanese folks talked about their efforts of "porting" Plan
9 on top of L4 at last years IWP9 -- I wonder if they've made any
further progress...
-eric
David Leimbach
Eric Van Hensbergen
I would be tempted to draw the same conclusion if other
implementations didn't seem to do a better job. Granted, our existing
points of comparison are highly specialized, but I still believe we
can accommodate both specialized and generalized cases as well as find
middle ground which may make the most sense for applications.
Further, I wonder if some of our locking interfaces may be better
built using some of the experiences of the past 20 years -- in
particular for larger SMP. Also, I wonder if we have the right set of
abstractions for our locking and queueing primitives for all
architectures. In particular -- if massive multi-core architectures
evolve to support IPC more natively, we'll want to take advantage of
those primitives.
Another examples is whether or not we could make better use of the
reservation based schemes on modern PPC versus the TAS model. It just
seems like given the architectural differences between the various
platforms we support, we might be able to do better native versions of
higher level primitives rather than just providing uniform support for
lower level primitives and always basing the higher level primitives
on that.
> Perhaps someone told them the software people wanted
> some of this stuff, but I've got my doubts!
Well, we can put ourselves in the position of requesting that stuff.
Designs for next generation Blue Genes and Power processors are still
in flux. One of the downsides of focusing on the available generation
is that we are losing out on the ability to try and affect the next
generation(s).
-eric
Eric Van Hensbergen
I think most of the issues we are facing are due to somewhat difficult
esoteric network interfaces combined with a single 700 MHz simple
embedded in-order processor. That being said however, any advantages
we can get on the relatively slow hardware should benefit the
efficiency (if not the latency and performance) of the faster
platforms. Even if we can push peak on our platform it won't help us
if we are chewing up cpu cycles that we need for computation.
-eric
Charles Forsyth
> embedded in-order processor.
there's actually some parallelism inside that processor: it's not that simple-minded,
just a little slow for what it's asked to do (even if there's no work to be done on the data).
>That being said however, any advantages we can get on the relatively
>slow hardware should benefit the efficiency (if not the latency and performance) of the faster
i think there's quite a bit of scope for performance improvements without doing violence
to the overall structure or messing up the implementation. i hope some things end up
being smaller and cleaner.
Eric Van Hensbergen
> >slow hardware should benefit the efficiency (if not the latency and performance) of the faster
>
> i think there's quite a bit of scope for performance improvements without doing violence
> to the overall structure or messing up the implementation. i hope some things end up
> being smaller and cleaner.
>
Agreed. Performance does not necessarily equal complexity. Neither
does allowing specialization -- I think specialization enables
simplification and clarity in many situations.
-eric
David Leimbach
ron minnich
> Not so strangely, it's using the version of gcc I had to use to build
> pistachio on the G5 that Ron couldn't get going with whatever was on his Red
> Hat system :-)
yes, the l4 build system gets annoyed when a .so is not a .so but is,
in fact an ldscript:
ls -l /usr/lib/libc.so
-rw-r--r-- 1 root root 238 2007-07-08 04:41 /usr/lib/libc.so
[rminnich@xcpu ~]$ tail /usr/lib/libc.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED (
/lib/ld-linux.so.2 ) )
makes you wonder why the bother with a suffix.
ron
David Leimbach
ron
Andrew Wingorodov
> Is Plan9 has a microkernel architecture?
>
i found the answer
http://harmful.cat-v.org/software/andy_tanenbaum
never mind
--
www.andr.ru