[9fans] what about microkernel?

[9fans] what about microkernel?

[Andrew Wingorodov]

Is Plan9 has a microkernel architecture?

-- 
www.andr.ru

Re: [9fans] what about microkernel?

[Lorenzo Fernando Bivens de la Fuente]

No, as far as I know...

It is a small kernel, though...

Cheers!

On 10/6/07, Andrew Wingorodov <mail@andr.ru> wrote:
> Is Plan9 has a microkernel architecture?
>
> --
> www.andr.ru
>
>
>

Re: [9fans] what about microkernel?

[johnny]

I think the answer is in here:
http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
But I think it's not.

Re: [9fans] what about microkernel?

[Charles Forsyth]

> Is Plan9 has a microkernel architecture?

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.

[9fans] Re: what about microkernel?

[Andrew Wingorodov]

Charles Forsyth <forsyth@terzarima.net> wrote:
> 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

Re: [9fans] Re: what about microkernel?

[Charles Forsyth]

> you mean, the all 9 subsystems works through 9P and filesystems,
> 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).

Re: [9fans] Re: what about microkernel?

[David Leimbach]

On 10/6/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> > you mean, the all 9 subsystems works through 9P and filesystems,
> > 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).

It's "open sourced" now, as of a few weeks ago.

Ever looked at the L4 family of microkernels?

Re: [9fans] Re: what about microkernel?

[ron minnich]

On 10/7/07, David Leimbach <leimy2k@gmail.com> wrote:

> 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

Re: [9fans] Re: what about microkernel?

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

TUD:OS is pretty neat. I'd like to take Nemesis out for a spin as well, but
I've not the time now.

On 10/7/07, David Leimbach <leimy2k@gmail.com> wrote:
>
> On 10/6/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> > > you mean, the all 9 subsystems works through 9P and filesystems,
> > > 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).
>
> It's "open sourced" now, as of a few weeks ago.
>
> Ever looked at the L4 family of microkernels?
>



-- 
    "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

[-- Attachment #2: Type: text/html, Size: 2133 bytes --]

Re: [9fans] Re: what about microkernel?

[erik quanstrom]

>> 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.

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

[9fans] Re: what about microkernel?

[Andrew Wingorodov]

David Leimbach <leimy2k@gmail.com> wrote:
> On 10/6/07, Charles Forsyth <forsyth@terzarima.net> wrote:
>> qnx is probably the most reasonable so-called microkernel
>> i've seen described
>> (but i haven't seen their code).
> 
> It's "open sourced" now, as of a few weeks ago.

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

Re: [9fans] Re: what about microkernel?

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

L4 != Linux (although there is L4Linux)


On 10/7/07, Andrew Wingorodov <mail@andr.ru> wrote:
>
> David Leimbach <leimy2k@gmail.com> wrote:
> > On 10/6/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> >> qnx is probably the most reasonable so-called microkernel
> >> i've seen described
> >> (but i haven't seen their code).
> >
> > It's "open sourced" now, as of a few weeks ago.
>
> 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
>
>
>


-- 
    "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

[-- Attachment #2: Type: text/html, Size: 2051 bytes --]

Re: [9fans] Re: what about microkernel?

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On 10/7/07, Andrew Wingorodov <mail@andr.ru> wrote:
>
> David Leimbach <leimy2k@gmail.com> wrote:
> > On 10/6/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> >> qnx is probably the most reasonable so-called microkernel
> >> i've seen described
> >> (but i haven't seen their code).
> >
> > It's "open sourced" now, as of a few weeks ago.
>
> 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
>

L4 has basically nothing to do with Linux.  There are ports of Linux to L4,
using it as a hardware architecture though, which provides many of the
benefits of things like Xen (running multiple instances of Linux etc)

[-- Attachment #2: Type: text/html, Size: 1382 bytes --]

Re: [9fans] Re: what about microkernel?

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On 10/7/07, ron minnich <rminnich@gmail.com> wrote:
>
> On 10/7/07, David Leimbach <leimy2k@gmail.com> wrote:
>
> > 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
>

Yep, it was pretty compiler specific back when I used it on my Power Macs,
and may still be if we're talking about the Pistachio implementation.

Darwin was also ported to it (Darbat -
http://www.osnews.com/story.php/15162/Darbat-0.2-Released/) also.

Dave

[-- Attachment #2: Type: text/html, Size: 1154 bytes --]

Re: [9fans] Re: what about microkernel?

[Francisco J Ballesteros]

That was the idea. Jochen Liedtke suggested that ukernels should not
be portable, just their interface. His ukernel was hand tuned for a particular
hw/compiler, afaik.

On 10/7/07, David Leimbach <leimy2k@gmail.com> wrote:
>
>
> On 10/7/07, ron minnich <rminnich@gmail.com> wrote:
> > On 10/7/07, David Leimbach <leimy2k@gmail.com> wrote:
> >
> > > 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
> >
>
> Yep, it was pretty compiler specific back when I used it on my Power Macs,
> and may still be if we're talking about the Pistachio implementation.
>
> Darwin was also ported to it (Darbat -
> http://www.osnews.com/story.php/15162/Darbat-0.2-Released/
> ) also.
>
> Dave

Re: [9fans] Re: what about microkernel?

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

His original Kernel, L3, was written in pure assembly for x86, using every
trick possible.

On 10/7/07, Francisco J Ballesteros <nemo@lsub.org> wrote:
>
> That was the idea. Jochen Liedtke suggested that ukernels should not
> be portable, just their interface. His ukernel was hand tuned for a
> particular
> hw/compiler, afaik.
>
> On 10/7/07, David Leimbach <leimy2k@gmail.com> wrote:
> >
> >
> > On 10/7/07, ron minnich <rminnich@gmail.com> wrote:
> > > On 10/7/07, David Leimbach <leimy2k@gmail.com> wrote:
> > >
> > > > 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
> > >
> >
> > Yep, it was pretty compiler specific back when I used it on my Power
> Macs,
> > and may still be if we're talking about the Pistachio implementation.
> >
> > Darwin was also ported to it (Darbat -
> > http://www.osnews.com/story.php/15162/Darbat-0.2-Released/
> > ) also.
> >
> > Dave
>



-- 
    "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

[-- Attachment #2: Type: text/html, Size: 2492 bytes --]

Re: [9fans] Re: what about microkernel?

[Charles Forsyth]

> His original Kernel, L3, was written in pure assembly for x86, using every
> trick possible.

one way to pass the time, i suppose.

Re: [9fans] Re: what about microkernel?

[erik quanstrom]

> 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.  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

Re: [9fans] Re: what about microkernel?

[Eric Van Hensbergen]

On 10/8/07, erik quanstrom <quanstro@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

Re: [9fans] Re: what about microkernel?

[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.

Re: [9fans] Re: what about microkernel?

[erik quanstrom]

> 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).

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

Re: [9fans] Re: what about microkernel?

[Charles Forsyth]

> 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

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!

Re: [9fans] Re: what about microkernel?

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

On 10/8/07, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>
> On 10/8/07, erik quanstrom <quanstro@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).


Yep, L4 has a high level and low level spec for different architectures.  I
think there's like up to 255 virtual registers, which I think can actually
be realized in real hardware on the Itanium port.

IPC is just register swapping then.  IPC is also synchronous only.

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...


I'd be very curious to know how that went...



        -eric
>

[-- Attachment #2: Type: text/html, Size: 3454 bytes --]

Re: [9fans] Re: what about microkernel?

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

On 10/8/07, Charles Forsyth <forsyth@terzarima.net> wrote:
>
> > 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
>
> 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!
>
> We can't make em faster, so we'll make more of em and put em on one die!
Now deal with shared memory problems...

== Hey look Erlang!

And now suddenly CSP gets more attention again too!

Dave

[-- Attachment #2: Type: text/html, Size: 1415 bytes --]

Re: [9fans] Re: what about microkernel?

[Eric Van Hensbergen]

On 10/8/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> > 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
>
> 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!
>

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

Re: [9fans] Re: what about microkernel?

[Eric Van Hensbergen]

On 10/8/07, erik quanstrom <quanstro@coraid.com> wrote:
> > 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).
>
> 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.
>

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

Re: [9fans] Re: what about microkernel?

[Charles Forsyth]

> esoteric network interfaces combined with a single 700 MHz simple
> 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.

Re: [9fans] Re: what about microkernel?

[Eric Van Hensbergen]

On 10/8/07, Charles Forsyth <forsyth@terzarima.net> wrote:
>
> >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.
>

Agreed.  Performance does not necessarily equal complexity.  Neither
does allowing specialization -- I think specialization enables
simplification and clarity in many situations.

       -eric

Re: [9fans] Re: what about microkernel?

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On 10/8/07, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>
> On 10/8/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> >
> > >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.
> >
>
> Agreed.  Performance does not necessarily equal complexity.  Neither
> does allowing specialization -- I think specialization enables
> simplification and clarity in many situations.
>
>        -eric
>


Looks like at&t's new tilt is running L4/Linux :-)

Based on a qualcomm chipset I'd bet it's either Iguana based or something
else.

Buddy of mine posted this:

http://paste.lisp.org/display/48981

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 :-)

Dave

[-- Attachment #2: Type: text/html, Size: 1937 bytes --]

Re: [9fans] Re: what about microkernel?

[ron minnich]

On 10/10/07, David Leimbach <leimy2k@gmail.com> wrote:

> 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

Re: [9fans] Re: what about microkernel?

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On 10/10/07, ron minnich <rminnich@gmail.com> wrote:
>
> On 10/10/07, David Leimbach <leimy2k@gmail.com> wrote:
>
> > 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.


s/a suffix//


ron
>

[-- Attachment #2: Type: text/html, Size: 1431 bytes --]

[9fans] Re: what about microkernel?

[Andrew Wingorodov]

Andrew Wingorodov <mail@andr.ru> wrote:
> Is Plan9 has a microkernel architecture?
> 

i found the answer

http://harmful.cat-v.org/software/andy_tanenbaum

never mind

-- 
www.andr.ru