Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[erik quanstrom]

i don't see how you can blame hurd's vaporware status
on switching from mach to l4.  that happened quite reciently.
they were coding for hurd in 1990.

- erik

On Wed Dec  6 17:39:26 EST 2006, litestar@gmail.com wrote:
> How about two teams that are going in different directions & never
> getting anything done?
> They didn't even finsh HURD/Mach, now they're looking into HURD/L4. I
> like L4 for alot of things, but they didn't even finish the first one
> really...
> 
> On 12/6/06, erik quanstrom <quanstro@coraid.com> wrote:
> 
> > funny, nether gcc nor emacs took that long.  so it's not an
> > inherent property of stallman's direction.  so it must be
> > something else ... like maybe the design, or lack there of?
> >
> > - erik

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[Harri Haataja]

On Wed, Dec 06, 2006 at 05:52:49PM -0500, erik quanstrom wrote:
> i don't see how you can blame hurd's vaporware status
> on switching from mach to l4.  that happened quite reciently.
> they were coding for hurd in 1990.

Adding to the handwaving:

Generally problems in hurd seem to be blamed on the kernel. They say
mach just isn't any good so that didn't work out. I don't know if the l4
thing got anywhere and it seems that at least part of the crowd
(hurd-ng) is now arguing about profound ideas at the moment without any
code trying to figure out how to start a new(?) system without having
ever ro start over again. (<-- that's all just hand-waving, though. ianahd)

If I got the picture, there seems to be one running Hurd
(http://www.debian.org/ports/hurd/) and they're not happy with Mach and
aren't continuing. Then there's a number of groups looking for the
alternative. Maybe that's progress, but if the running mach version
doesn't go forward and no new version reaches a running state, the
usable Hurd will seem to be stuck in that state.

-- 
<Murgatroyd> You know you've been playing Nethack too much when...
<Murgatroyd> You look both ways down the corridor, start to sweat... then
realise you're looking at your EMail address.

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[LiteStar numnums]

The last thing I heard of the L4 port was that they had recently been
able to load an executable without a kernel panic. Not really the
progress you'd hope for (esp. considering that there are a bunch of
robust OSs based upon L4, such as L4Linux & TUD:OS).

The Wikipedia article says that there was further discussion as to
wether or not they should switch to the later L4 spec, or the Coyotos
kernel.

The 0.2 Hurd/Mach does have some nice live CDs out there currently,
although they aren't of much use considering Hurd's 'feature set'.

On 2/8/07, Harri Haataja <harriha@mail.student.oulu.fi> wrote:
> On Wed, Dec 06, 2006 at 05:52:49PM -0500, erik quanstrom wrote:
> > i don't see how you can blame hurd's vaporware status
> > on switching from mach to l4.  that happened quite reciently.
> > they were coding for hurd in 1990.
>
> Adding to the handwaving:
>
> Generally problems in hurd seem to be blamed on the kernel. They say
> mach just isn't any good so that didn't work out. I don't know if the l4
> thing got anywhere and it seems that at least part of the crowd
> (hurd-ng) is now arguing about profound ideas at the moment without any
> code trying to figure out how to start a new(?) system without having
> ever ro start over again. (<-- that's all just hand-waving, though. ianahd)
>
> If I got the picture, there seems to be one running Hurd
> (http://www.debian.org/ports/hurd/) and they're not happy with Mach and
> aren't continuing. Then there's a number of groups looking for the
> alternative. Maybe that's progress, but if the running mach version
> doesn't go forward and no new version reaches a running state, the
> usable Hurd will seem to be stuck in that state.
>
> --
> <Murgatroyd> You know you've been playing Nethack too much when...
> <Murgatroyd> You look both ways down the corridor, start to sweat... then
> realise you're looking at your EMail address.
>


-- 
If work and leisure are soon to be subordinated to this one utopian
principle -- absolute busyness -- then utopia and melancholy will come
to coincide: an age without conflict will dawn, perpetually busy --
and without consciousness.

 -- Günter Grass

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[erik quanstrom]

On Wed Dec  6 16:29:07 EST 2006, jorge-plan9@magma.com.ni wrote:
> The Hurd can be run as a user space process inside The Hurd.  Made
> feasable because of its multi-server nature: the Kernel almost does
> not do I/O.  Thus The Hurd allegedly can be debugged and developed
> more easily.

if that were true, why has it taken almost 20 years to get a useful system?

- erik

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[John Floren]

On 12/6/06, erik quanstrom <quanstro@coraid.com> wrote:
> On Wed Dec  6 16:29:07 EST 2006, jorge-plan9@magma.com.ni wrote:
> > The Hurd can be run as a user space process inside The Hurd.  Made
> > feasable because of its multi-server nature: the Kernel almost does
> > not do I/O.  Thus The Hurd allegedly can be debugged and developed
> > more easily.
>
> if that were true, why has it taken almost 20 years to get a useful system?
>
> - erik
>

Because RMS is in charge?


John
-- 
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[erik quanstrom]

On Wed Dec  6 17:27:37 EST 2006, slawmaster@gmail.com wrote:
> > if that were true, why has it taken almost 20 years to get a useful system?
> >
> > - erik
> >
> 
> Because RMS is in charge?

funny, nether gcc nor emacs took that long.  so it's not an
inherent property of stallman's direction.  so it must be
something else ... like maybe the design, or lack there of?

- erik

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[LiteStar numnums]

How about two teams that are going in different directions & never
getting anything done?
They didn't even finsh HURD/Mach, now they're looking into HURD/L4. I
like L4 for alot of things, but they didn't even finish the first one
really...

On 12/6/06, erik quanstrom <quanstro@coraid.com> wrote:

> funny, nether gcc nor emacs took that long.  so it's not an
> inherent property of stallman's direction.  so it must be
> something else ... like maybe the design, or lack there of?
>
> - erik
>


-- 
If work and leisure are soon to be subordinated to this one utopian
principle -- absolute busyness -- then utopia and melancholy will come
to coincide: an age without conflict will dawn, perpetually busy --
and without consciousness.

 -- Günter Grass

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[John Floren]

On 12/6/06, erik quanstrom <quanstro@coraid.com> wrote:
> On Wed Dec  6 17:27:37 EST 2006, slawmaster@gmail.com wrote:
> > > if that were true, why has it taken almost 20 years to get a useful system?
> > >
> > > - erik
> > >
> >
> > Because RMS is in charge?
>
> funny, nether gcc nor emacs took that long.  so it's not an
> inherent property of stallman's direction.  so it must be
> something else ... like maybe the design, or lack there of?
>
> - erik
>

I think when Stallman did gcc and emacs, he wasn't so much in the
current state. Isn't emacs currently stalled, anyway, as he demands
that they fix /every/ bug in it? It's a very worthy goal, but the way
it sounds, he's doing it in a way that will make the next emacs
release years in the future.

I pretty much just consider him a few noodles short of a bowl and
ignore the man. ;-)

John
-- 
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[LiteStar numnums]

[quote]
 I think when Stallman did gcc and emacs, he wasn't so much in the
current state. Isn't emacs currently stalled, anyway, as he demands
that they fix /every/ bug in it? It's a very worthy goal, but the way
it sounds, he's doing it in a way that will make the next emacs
release years in the future.
....
This is the same emacs that lost the leading '1' from it's version number
since it would never see the version '2' light of day... ;-)


-- 
If work and leisure are soon to be subordinated to this one utopian
principle -- absolute busyness -- then utopia and melancholy will come
to coincide: an age without conflict will dawn, perpetually busy --
and without consciousness.

 -- Günter Grass

Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[John Floren]

On 12/6/06, LiteStar numnums <litestar@gmail.com> wrote:
> [quote]
>  I think when Stallman did gcc and emacs, he wasn't so much in the
> current state. Isn't emacs currently stalled, anyway, as he demands
> that they fix /every/ bug in it? It's a very worthy goal, but the way
> it sounds, he's doing it in a way that will make the next emacs
> release years in the future.
> ....
> This is the same emacs that lost the leading '1' from it's version number
> since it would never see the version '2' light of day... ;-)
>

I think perhaps the time is approaching to make the switch to xemacs.
I've been wanting to get away from RMS's wacko crap for a while now
;-)


John "Talks About Emacs on a Plan 9 List" Floren
-- 
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

[9fans] extending xen to allow driver development in Plan 9

[ron minnich]

This is mostly for Richard Miller but I don't have his email. But if
you are interested in Xen, read along.

We have an ok xen environment going. Why are we doing this? Per a
certain person at xyz.com, we are looking at giving people a usable
xen-based plan 9 environment, and at the same time letting them do
driver work from Plan 9 by "poking holes" in Xen to let Plan 9 at the
real hardware. Xen supports this, we think, although we have not got
it going yet ...

I already like the situation thus far, as Plan 9 under Xen is a ton
faster than Plan 9 under qemu. You have to see it to believe it; if
anything, the Xen advantage is better than it used to be. I was
surprised.

to get to the point of poking holes in Xen, it turned out I need
pcifront. For pcifront I need xenbus. for xenbus I need xenstore.

There is xenstore support in Plan 9 already, but ...

The xenstore sez: "incomplete". What would it take to complete it?
conservative use of locks in the short term as a hack for really doing
it right in the long term? The comment is this:

 * XXX This is incomplete - needs multiplexing of request/response protocol
 * and locking between driver and kernel-only xenstore_read/write interface.

Should we set up queues for request/response? The locking seems simple
enough, is there something I'm missing?

ron

Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9

[Georg Lehner]

"ron minnich" <rminnich@gmail.com> writes:
...
> We have an ok xen environment going. Why are we doing this? Per a
> certain person at xyz.com, we are looking at giving people a usable
> xen-based plan 9 environment, and at the same time letting them do
> driver work from Plan 9 by "poking holes" in Xen to let Plan 9 at the
> real hardware. Xen supports this, we think, although we have not got
> it going yet ...
>
> I already like the situation thus far, as Plan 9 under Xen is a ton
> faster than Plan 9 under qemu. You have to see it to believe it; if
> anything, the Xen advantage is better than it used to be. I was
> surprised.
...

I have a similar situation:

- Xen helps me run several Plan9's one the same hardware

- I can give my users a Plan9 environment without taking away the OS
  they are used to work with

- Xen is much faster then Qemu, ok for production use

- as Richard Miller said: ".. the whole point of xen is that physical
  devices become Somebody Else's Problem."

However I think that the same goals could be achieved more natural,
even faster, more stable and more generally aplicable if Plan9 could
be run (self)hosted.

The Hurd can be run as a user space process inside The Hurd.  Made
feasable because of its multi-server nature: the Kernel almost does
not do I/O.  Thus The Hurd allegedly can be debugged and developed
more easily.

I guess the Plan9 Kernel could be separated in two layers, the upper
one just doing "high-level" and 9P-protocol stuff, and a lower one,
providing the #-channel interfaces to the upper layer and doing I/O.

The lower layer could either be comprised of hardware drivers for the
real hardware, or a hosting layer which intermediates between the
block devices and memory managment operations of a certain hosting
operating system and the #-channel interface to the upper layer.

Maybe this approach could also clean up the duplication of code
between 9loader and kernel I have read about in some Plan9 document.

Hardware driver development could also be eased by this approach,
since it is probably easier to pass certain hardware through to a
Linux process (the hosted Plan9 instance), than to go through the
complexities of Xen-Hypervisor - dom0 Linux - domU Plan9 interaction.

And: I know that this approach probably would increase complexity and
reduce performance with respect to the current Plan9 kernel.

Initially I have started to browse the Plan9 kernel source code, Linux
kernel docs, x86 assembler manuals etc., but I realized very fast,
that my spare time will never be sufficient to spot out all required
points to get anywhere with such a project.  However maybe there are
some folks out there who like the idea and have the knowledge to do
it.

Best Regards,

    Jorge-León