[9fans] Plan 9 on L4

[David Leimbach]

Recently found a paper (again) documenting some work going on here.

I've lately sort of had a resurrected interest in OKL4, and I'm always interested in Plan 9 stuff, so I was wondering what's happened here or if there's any code to show for it.

It seems like an effort that would take more than one person, but I'm spending some of my spare time investigating L4 a little more in depth than I had previously, and trying to understand what it would take to port Plan 9 to this platform.

I'm not announcing this as a project at this point, as I don't know what the heck kind of time I'm going to have.

Dave

[YAMANASHI Takeshi]

As I heard, the largest work in porting Plan 9 to L4 enviroment
is rewriting Plan 9's C code base to be compiled on gcc
as L4 uses the compiler for its development.

The developers of LP49 themselves could chime in, but here is the link
to the project.
You might be surprised how much of Plan 9 has been rewritten in LP49.

http://research.nii.ac.jp/H2O/LP49/LP49-e.html
--

--
YAMANASHI Takeshi

[David Leimbach]

This looks really great!  Thanks!

[David Leimbach]

Well I've got it booted in VMWare from the tarball of just a few weeks back and it looks pretty nice!

[Tim Newsham]

Any reason why they prefer to rewrite large portions of

code to use gcc rather than making use of different toolchains

for the L4 kernel and the plan9 subsystems? It seems like the

latter would be a lot less effort and result in a system that was

easier to track the original sources going forward.

--
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

[lu...@proxima.alt.za]

> Any reason why they prefer to rewrite large portions of
> code to use gcc rather than making use of different toolchains
> for the L4 kernel and the plan9 subsystems? It seems like the
> latter would be a lot less effort and result in a system that was
> easier to track the original sources going forward.

Seems like portability isn't of interest to anyone, anymore.

As Russ suggested to me a while back, the Plan 9 kernel should not
require massive rewriting to port to GCC. Go figure.

++L

[Corey Thomasson]

On 1/8/2010 1:10 PM, lu...@proxima.alt.za wrote:
>
> Seems like portability isn't of interest to anyone, anymore.
>
> As Russ suggested to me a while back, the Plan 9 kernel should not
> require massive rewriting to port to GCC. Go figure.
>
>

Should not but does? Because of gcc or lack of portability in plan 9's code?

[Patrick Kelly]

On Jan 8, 2010, at 12:59 PM, Tim Newsham <tim.n...@gmail.com> wrote:

Any reason why they prefer to rewrite large portions of

code to use gcc rather than making use of different toolchains

for the L4 kernel and the plan9 subsystems? It seems like the

latter would be a lot less effort and result in a system that was

easier to track the original sources going forward.

But GCC is part of the holy trinity...

People are funny like that.

[David Leimbach]

I might be having a hard time with the Japanese, but my impression is that the plan 9 processes are now also L4 userspace servers.  This makes me think they're not running a paravirtualized Plan 9 on L4, but put L4 INTO Plan 9.

If they're using pistachio for L4, the code is/was pretty GNU tool chain specific.  I mean it doesn't compile with GCC 4 yet to the best of my knowledge.  So rather than porting the microkernel, which might be trickier, they decided to port Plan 9, which may have been a lot easier.

This approach is not what I was thinking about doing, if my belief of what was done is correct (I suppose I can go look at the source anytime now), and I would approach it a lot more the same way you had mentioned, which is leave Plan 9 on the kencc compilers, and L4 to GNU, then make Plan 9 an ELF image so it could be loaded by L4's piggyback process or the GRUB multi-server spec.

The approach of L4 in Plan 9 has its own benefits over just sticking Plan 9 in as a user space server paravirtualized to L4 of course that are neat to explore as well.  I just wanted to go about it in a slightly different way.

Dave

[ron minnich]

actually, code that uses gcc seems to require massive rewrite just to
accommodate different versions of gcc. This has been a huge problem
for 10 years in coreboot. We just have to deal with it. Just look at
the recent Linux security hole attributed to a gcc optimization ...

Experience shows that the mods needed for plan 9 code for gcc can be
less than the mods needed just to forward port code between different
versions of gcc. It's quite amazing.

ron

[lu...@proxima.alt.za]

> Should not but does? Because of gcc or lack of portability in plan 9's code?

Good question. In my experience, Plan 9 code is very portable,
although occasionally one needs to add the odd struct or union label
that the Plan 9 toolchain does not require.

If I understand correctly, the biggest problem with GCC is that
developers cannot resist using each and every feature.

++L

[Tim Newsham]

> I might be having a hard time with the Japanese, but my impression is that
> the plan 9 processes are now also L4 userspace servers. This makes me think
> they're not running a paravirtualized Plan 9 on L4, but put L4 INTO Plan 9.

The paper I found online said they're currently implementing plan9
as a single server and eventually plan to split it off into multiple
servers. Either way, the plan 9 services sit on top of L4. I still
dont understand why they necessarily have to be built with the same
toolchain that builds the L4 kernel itself. Even if its embedded
into the kernel as a root server, shouldn't it be possible to compile
it separately and embed the resulting binary?

fwiw I haven't peekd at the code.

> Dave

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

[Dave Eckhardt]

> actually, code that uses gcc seems to require massive
> rewrite just to accommodate different versions of gcc.

I think the most "fun" I had was when the meaning of some
inline asm() changed. Not a "massive rewrite", since it
was only one line, but it was none the less painful.

Dave Eckhardt

[Eric Van Hensbergen]

Of course it all depends on what base of L4 they are working with, but you'd need to generate Plan 9 native versions of the L4 IPCs and IPC mechanisms (which in many ways is the crux of the L4 microkernel). L4 tends to be super optimized so its likely there are all sorts of hairy GCC-isms in the way the structure components of the IPCs are constructed as well as architecture specific aspects of IPC. Given the relative complexity and trickery at work within L4, porting Plan 9 to GCC is likely much more straightforward as the code base you are starting with is easier to understand.

Of course, IMHO the more interesting thing beyond creating a "Plan 9 personality" for L4 is to look at using the L4 microkernel as a mux for 9P messages and building a system based on that (versus the standard L4 IPC protocol).

-eric

[Patrick Kelly]

On Jan 8, 2010, at 2:43 PM, Tim Newsham <new...@lava.net> wrote:

>> I might be having a hard time with the Japanese, but my impression
>> is that
>> the plan 9 processes are now also L4 userspace servers. This makes
>> me think
>> they're not running a paravirtualized Plan 9 on L4, but put L4 INTO
>> Plan 9.
>
> The paper I found online said they're currently implementing plan9
> as a single server and eventually plan to split it off into multiple
> servers. Either way, the plan 9 services sit on top of L4. I still
> dont understand why they necessarily have to be built with the same
> toolchain that builds the L4 kernel itself. Even if its embedded
> into the kernel as a root server, shouldn't it be possible to compile
> it separately and embed the resulting binary?

possible but you would have to look at the code to see exacly whats
going on

[Richard Miller]

> Just look at
> the recent Linux security hole attributed to a gcc optimization ...

op-ti-mize [verb (trans.)] ... (gcc) to modify executable code so
that it fails more quickly