[9fans] Glendix?

[9fans] Glendix?

[Anant Narayanan]

Hi All,

I picked this idea from the GSoC07 Wiki page: porting the Plan 9
userspace to the Linux kernel.

I am aware that Plan9Port is something very close to the goal, but I
think we can eliminate all of the GNU and X dependencies and have a pure
Linux/Plan9 setup. Why Linux? Simply because it supports a wide-range of
hardware, is one of the most documented free kernels out there, and
already has the support of many developers.

I think there are 3 ways in which we can do this:

1) Modify the Linux kernel to present a 9P interface to itself (too
hard, almost like re-writing several important parts of the kernel)
2) Modify the Plan 9 userspace to work with POSIX (Yuck, and Plan9Port
already does this)
3) Create a custom INIT process which will be responsible for providing
all the "plan 9 kernelish" features that userspace programs expect (for
eg. providing the /net directory), so that all of them can run unmodified.

I am of the opinion that (3) is the best way to go about it. With the
KenCC port to Linux (a result of Kris' work for this year's summer of
code), we can generate ELF executables. Recompiling all of Plan 9's
userspace should then do the trick, if we get the INIT process right.

Am I on the right track?

--
Anant

P.S. I will be doing this project as a final-year undergraduate thesis
at my university, which means I will have time and resources to attempt
this - about 4 months of it :)

Re: [9fans] Glendix?

[Gorka Guardiola]

On Nov 13, 2007 10:28 AM, Anant Narayanan <anant@kix.in> wrote:
> Am I on the right track?
>

See THNX by rminnich, an lguest port of plan 9 with drawterm using framebuffers.
It is very close to what you want.
-- 
- curiosity sKilled the cat

Re: [9fans] Glendix?

[Uriel]

Actually, I suspect THNX is completely different from what he wants.
As far as I know THNX doesn't run any plan9 userspace on linux.

What might be more useful is to use Inferno to provide things like
/net and /draw as an start (mounted over v9fs) (and perhaps later on
replace
them with custom userspace servers.

uriel

On Nov 13, 2007 11:05 AM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Nov 13, 2007 10:28 AM, Anant Narayanan <anant@kix.in> wrote:
> > Am I on the right track?
> >
>
> See THNX by rminnich, an lguest port of plan 9 with drawterm using framebuffers.
> It is very close to what you want.
> --
> - curiosity sKilled the cat
>

Re: [9fans] Glendix?

[Gorka Guardiola]

On Nov 13, 2007 11:14 AM, Uriel <uriel99@gmail.com> wrote:
> Actually, I suspect THNX is completely different from what he wants.
> As far as I know THNX doesn't run any plan9 userspace on linux.
>

No, it runs proper Plan 9 using linux as drivers. Which is *exactly*
what he asked for.

> What might be more useful is to use Inferno to provide things like

Why would that be?.

> /net and /draw as an start (mounted over v9fs) (and perhaps later on
> replace
> them with custom userspace servers.
>
> uriel
>

You still have X under at least, unless there is a frambuffer version
of inferno I am not aware of. Anyway, inferno is not Plan 9 even
if it looks very similar if you squint.

X means loads of other stuff  it depends on which have already been trimmed out
of THNX.

-- 
- curiosity sKilled the cat

Re: [9fans] Glendix?

[David Leimbach]

>
> You still have X under at least, unless there is a frambuffer version
> of inferno I am not aware of. Anyway, inferno is not Plan 9 even
> if it looks very similar if you squint.

There is or at least was a framebuffer linux version of inferno to my
recollection.>

Re: [9fans] Glendix?

[Alexander Sychev]

On Tue, 13 Nov 2007 07:25:39 -0700, David Leimbach <leimy2k@gmail.com>  
wrote:

>
> There is or at least was a framebuffer linux version of inferno to my
> recollection.>

There is one :-). Now the implementation of the linux framebuffer support  
can be found in the archive of inferno mailing list, but I going to make a  
project inferno-fb on code.google.com and upload the sources.


-- 
Best regards,
   santucco

Re: [9fans] Glendix?

[Joel C. Salomon]

On Nov 13, 2007 5:05 AM, Gorka Guardiola <paurea@gmail.com> wrote:
> See THNX by rminnich, an lguest port of plan 9 with drawterm using framebuffers.
> It is very close to what you want.

Actually, an early version of P9P for Windows, 9pm, is closer to
Anant's idea.  See <http://swtch.com/usr/local/plan9/9pm/README.html>.

--Joel

Re: [9fans] Glendix?

[Charles Forsyth]

> Am I on the right track?

especially if it's a final-year project, i'd pick something
that's more than a demonstration of endurance.

Re: [9fans] Glendix?

[roger peppe]

> I am aware that Plan9Port is something very close to the goal, but I
> think we can eliminate all of the GNU and X dependencies and have a pure
> Linux/Plan9 setup. Why Linux? Simply because it supports a wide-range of
> hardware, is one of the most documented free kernels out there, and
> already has the support of many developers.

you could do this, but i think it would end up being quite unsatisfactory,
as you'd surely end up wanting to use aspects of linux other than its drivers.

so you might get more hardware support, but you'd lose all the userspace
code, so would it really end up that much more capable?

Re: [9fans] Glendix?

[Anant Narayanan]

Hi,

> so you might get more hardware support, but you'd lose all the userspace
> code, so would it really end up that much more capable?

I don't understand what "lose all the userspace code" means. The
objective of the exercise is to enable Plan 9's userspace to work
unmodified on Linux.

It boils down to Linux's drivers/schedulers/et.al. but Plan 9's
programming environment. You'd still use /net to do network programming,
use libdraw and not X, so to the programmer the fact that the
distribution is running the Linux kernel is not known.

Performance-wise, I see how it would be a bad idea; since read/write to
/net will ultimately result in a socket-like call, so there would be a
overhead.

--
Anant

Re: [9fans] Glendix?

[Uriel]

On Nov 13, 2007 11:47 AM, Anant Narayanan <anant@kix.in> wrote:
> Hi,
>
> > so you might get more hardware support, but you'd lose all the userspace
> > code, so would it really end up that much more capable?
>
> I don't understand what "lose all the userspace code" means. The
> objective of the exercise is to enable Plan 9's userspace to work
> unmodified on Linux.

I still think being able to run lunix programs in the same environment
would be quite useful (and not too hard, you could use namespaces
to build a more 'lunix friendly' environment inside glendix).
Otherwise it would not be too different from running native plan9
inside a VM as Gorka pointed out. (And that is is IMHO what makes THNX
not particularly useful, that it adds very little over just running
Plan 9 on qemu, or vmware, or whatever.

> It boils down to Linux's drivers/schedulers/et.al. but Plan 9's
> programming environment. You'd still use /net to do network programming,
> use libdraw and not X, so to the programmer the fact that the
> distribution is running the Linux kernel is not known.
>
> Performance-wise, I see how it would be a bad idea; since read/write to
> /net will ultimately result in a socket-like call, so there would be a
> overhead.

If that is an issue you could eventually swap inferno for an in-kernel
/net server (using the new 9p server bits of v9fs).

The beauty of the approach is that it works nicely in steps, and if
you want to do that change later on you wont need to change anything
else.

uriel

Re: [9fans] Glendix?

[erik quanstrom]

> Hi,
> 
> > so you might get more hardware support, but you'd lose all the userspace
> > code, so would it really end up that much more capable?
> 
> I don't understand what "lose all the userspace code" means. The
> objective of the exercise is to enable Plan 9's userspace to work
> unmodified on Linux.
> 
> It boils down to Linux's drivers/schedulers/et.al. but Plan 9's
> programming environment. You'd still use /net to do network programming,
> use libdraw and not X, so to the programmer the fact that the
> distribution is running the Linux kernel is not known.
> 
> Performance-wise, I see how it would be a bad idea; since read/write to
> /net will ultimately result in a socket-like call, so there would be a
> overhead.
> 
> --
> Anant

what an unholy marrage!

what happens when you're tracking a bug?  do you give up when
it enters linux?  how do you configure hardware if you're not
going to use the linux machinery?

why are linux schedulers interesting?

i think that rather than the best of both worlds, you'd end up
with the worst of both.  all the joys of linux administration and
yet no (insert favorite browser here).

- erik

Re: [9fans] Glendix?

[Uriel]

> what an unholy marrage!

I'm not sure marriage is ever holy...

> what happens when you're tracking a bug?  do you give up when
> it enters linux?  how do you configure hardware if you're not
> going to use the linux machinery?
>
> why are linux schedulers interesting?
>
> i think that rather than the best of both worlds, you'd end up
> with the worst of both.  all the joys of linux administration and
> yet no (insert favorite browser here).

Well, the goal is to try to get the best of both worlds: plan9 user
space environment and administration while taking advantage of linux
dirvers and allowing lunix programs to run inside a sandbox
(namespace).

Admittedly how one deals with udev and other such linux userspace
monsters might be  tricky, but I think that is the whole point, to
replace such things with saner Plan 9-based solutions.

Think of it as an exercises on how a linux distribution would look
like if they had learned something from Plan 9.

And while there are similarities with THNX, I think it is also quite
different, as far as understand it, the only way to run linux apps on
thnx is via VNC, which seems far from ideal (and you are still having
a lunix environment outside the plan9 environment).

In any case, I'm not sure I see the point of all this arguments before
not a single line of code has been written (and much less released),
the more people we have bringing plan9 technologies to the world the
better.

uriel

Re: [9fans] Glendix?

[roger peppe]

> allowing lunix programs to run inside a sandbox (namespace).

how do you do that?

Re: [9fans] Glendix?

[sqweek]

On Nov 13, 2007 10:47 PM, roger peppe <rogpeppe@gmail.com> wrote:
> > allowing lunix programs to run inside a sandbox (namespace).
>
> how do you do that?

 Linux has private namespaces (see CLONE_NEWNS in clone(2)), they're
just not used by standard linux tools afaik.
-sqweek

Re: [9fans] Glendix?

[Charles Forsyth]

> In any case, I'm not sure I see the point of all this arguments before
> not a single line of code has been written (and much less released),
> the more people we have bringing plan9 technologies to the world the
> better.

well, perhaps.  in this case, however, he's looking for a student project,
and one that's essentially a load of grunge work isn't a good choice.

> I picked this idea from the GSoC07 Wiki page: porting the Plan 9
> userspace to the Linux kernel.

it might or might not have been a good gsoc project, but i don't think
it's the best choice for a final year project, even if you're in Engineering not CS.
(the aims are often quite different for gsoc projects than for a final-year project.)

if you're looking for something plan9-related, i'd pick an application area
of interest to you that looks as though it could benefit from applying plan 9's
techniques, mechanisms, etc., and apply them in an implementation.
if you aim to finish in about 2 months, you should be done in time in 4, with write-up.
a modular project is always good, so if you've actually got spare time
at the end, you can add another component.  (for instance, if the project
is split into 9p server and 9p clients, you can add a different type of client
for the same service.)

the aim is to show plan 9 doing something simpler,
more flexibly, faster/easier (in development time or effort) than some existing
implementation, just because of name spaces and concurrent programming (say).
on the other hand you're not doing original research, so implementing or
reimplementing an existing idea should be fine — it's an exercise.
usually it's very helpful if non-specialists can assess the result.

it's just my experience dealing with undergraduate projects in the past.

Re: [9fans] Glendix?

[Anant Narayanan]

> well, perhaps.  in this case, however, he's looking for a student project,
> and one that's essentially a load of grunge work isn't a good choice.

I don't think grunge work is bad if the result is usable. Hence, what I
am trying to evaluate via the discussion is whether the result is
something that can actually be used by developers.

> it might or might not have been a good gsoc project, but i don't think
> it's the best choice for a final year project, even if you're in Engineering not CS.
> (the aims are often quite different for gsoc projects than for a final-year project.)

Incidentally, I am pursuing Computer Engineering - but syllabi can be
easily mistaken for a CS course, there's no difference.

> if you're looking for something plan9-related, i'd pick an application area
> of interest to you that looks as though it could benefit from applying plan 9's
> techniques, mechanisms, etc., and apply them in an implementation.
> if you aim to finish in about 2 months, you should be done in time in 4, with write-up.
> a modular project is always good, so if you've actually got spare time
> at the end, you can add another component.  (for instance, if the project
> is split into 9p server and 9p clients, you can add a different type of client
> for the same service.)

Thanks, I'll look some more and see if I can find more ideas.
(Trouble is, I already registered glendix.org ;))

--
Anant

Re: [9fans] Glendix?

[Bakul Shah]

> I don't think grunge work is bad if the result is usable. Hence, what I
> am trying to evaluate via the discussion is whether the result is
> something that can actually be used by developers.

The thing about grunge work is it always takes far longer
than you think it would.  Besides, when you enter the real
world you will have plenty of grunge work to do.  Why get a
head start on it?!

> > if you aim to finish in about 2 months, you should be done in time in 4, wi
> th write-up.
> > a modular project is always good, so if you've actually got spare time
> > at the end, you can add another component.  (for instance, if the project
> > is split into 9p server and 9p clients, you can add a different type of cli
> ent
> > for the same service.)

I will second that.  You can use any remaining time for all
sorts of things -- there is always something more to do.

Long ago a famous engineer/painter/architect/sculptor said
"Art is never finished, only abandoned".  It is the same with
final year projects.  What matters is the quality of what is
done. So pick a small canvas and paint a still life!
 
> Thanks, I'll look some more and see if I can find more ideas.
> (Trouble is, I already registered glendix.org ;))

Call whatever you build glendix. Most s/w projects have silly
names.  Not plan9 of course.

Re: [9fans] Glendix?

[erik quanstrom]

> Admittedly how one deals with udev and other such linux userspace
> monsters might be  tricky, but I think that is the whole point, to
> replace such things with saner Plan 9-based solutions.

i see two problems with this.

1.  linux interfaces change all the time, requiring constant linux tinkering.
2.  covering up the linux interface will always be imperfect.  you won't
be able to ignore it's existance and i think you underestimate the amount
of glue code required.  p9p succeedes because it refuses to do this.

i am reminded by a line from the labs' response to ast's usenix posting
   - UNIX can be successfully run as an application program
        `Run' perhaps, `successfully' no.  Name a product that succeeds
        by running UNIX as an application.

s/UNIX/Plan 9/g

- erik

reference: http://groups.google.com/group/comp.os.research/browse_thread/thread/7f0d9faf290b8ce2/598d4a31d5c1aac7?lnk=gst&q=presotto#598d4a31d5c1aac7

Re: [9fans] Glendix?

[Uriel]

> i am reminded by a line from the labs' response to ast's usenix posting
>    - UNIX can be successfully run as an application program
>         `Run' perhaps, `successfully' no.  Name a product that succeeds
>         by running UNIX as an application.
>
> s/UNIX/Plan 9/g

I love that post, but I don't think s/UNIX/Plan 9/g is valid, we are
not talking about microkernels here, and see also Inferno.

uriel

Re: [9fans] Glendix?

[erik quanstrom]

> > i am reminded by a line from the labs' response to ast's usenix posting
> >    - UNIX can be successfully run as an application program
> >         `Run' perhaps, `successfully' no.  Name a product that succeeds
> >         by running UNIX as an application.
> >
> > s/UNIX/Plan 9/g
> 
> I love that post, but I don't think s/UNIX/Plan 9/g is valid, we are
> not talking about microkernels here, and see also Inferno.

i'm not saying it can't be done.  osx is *nix run as an application on
a bastardized mach kernel.  but "microkernel" is an empty nonsequitor.

what i am saying is that the glue layer is going to be huge.  and like
mach needed to be compromized to run osx well, linux will need to
be hacked to run plan 9 well.

and personally, i don't see the appeal.  you've been the most vocal
opponent of layering goo like this.

- erik

Re: [9fans] Glendix?

[Iruata Souza]

> what i am saying is that the glue layer is going to be huge.  and like
> mach needed to be compromized to run osx well, linux will need to
> be hacked to run plan 9 well.
>

imho that work would be more well applied if directed to porting or
driver writing or something.
iru

Re: [9fans] Glendix?

[David Leimbach]

On Nov 13, 2007 9:19 AM, erik quanstrom <quanstro@coraid.com> wrote:
>
> > > i am reminded by a line from the labs' response to ast's usenix posting
> > >    - UNIX can be successfully run as an application program
> > >         `Run' perhaps, `successfully' no.  Name a product that succeeds
> > >         by running UNIX as an application.
> > >
> > > s/UNIX/Plan 9/g
> >
> > I love that post, but I don't think s/UNIX/Plan 9/g is valid, we are
> > not talking about microkernels here, and see also Inferno.
>
> i'm not saying it can't be done.  osx is *nix run as an application on
> a bastardized mach kernel.  but "microkernel" is an empty nonsequitor.

Not quite.  The mac os x kernel is XNU which stands for XNU's Not
Unix.  It might have mach inside, but the unix is in there too.

I used to run Mac OS X on my own custom kernels back in 2001 for "fun".

Dave

Re: [9fans] Glendix?

[Anant Narayanan]

> Admittedly how one deals with udev and other such linux userspace
> monsters might be  tricky, but I think that is the whole point, to
> replace such things with saner Plan 9-based solutions.

Off the top of my head, I don't think coming with a file-system approach
to dynamic devices would be that hard; say for example a notification
that a USB drive has just been plugged in and automounting it...

Can this already be done in Plan 9? :)

--
Anant

Re: [9fans] Glendix?

[Anant Narayanan]

Hi,

> what happens when you're tracking a bug?  do you give up when
> it enters linux?  how do you configure hardware if you're not
> going to use the linux machinery?

>From a very theoretical perspective, using a different userspace with
the Linux kernel shouldn't be all that difficult. I'm not sure how much
tied a traditional Linux userspace is to the kernel, so I don't the
answers to your questions.

> why are linux schedulers interesting?

Well, to be honest, I haven't looked at the Plan 9 schedulers; so
amongst the ones that we have seen so far, Linux has the most
interesting set of schedulers (purely from a classroom perspective).

> i think that rather than the best of both worlds, you'd end up
> with the worst of both.  all the joys of linux administration and
> yet no (insert favorite browser here).

So, the best of both worlds would mean the Plan 9 kernel and the GNU
userspace? Or perhaps Plan 9 wants to be single all his (her?) life ;)

--
Anant

Re: [9fans] Glendix?

[erik quanstrom]

> Well, to be honest, I haven't looked at the Plan 9 schedulers; so
> amongst the ones that we have seen so far, Linux has the most
> interesting set of schedulers (purely from a classroom perspective).
> 
> > i think that rather than the best of both worlds, you'd end up
> > with the worst of both.  all the joys of linux administration and
> > yet no (insert favorite browser here).
> 
> So, the best of both worlds would mean the Plan 9 kernel and the GNU
> userspace? Or perhaps Plan 9 wants to be single all his (her?) life ;)

the converse does not always hold.

- erik

Re: [9fans] Glendix?

[Joel C. Salomon]

On Nov 13, 2007 9:29 AM, Anant Narayanan <anant@kix.in> wrote:
> Or perhaps Plan 9 wants to be single all his (her?) life ;)

See <http://groups.google.com/group/comp.os.plan9/msg/e2e66725a9fb9855>:

"Under the Unix's tutelage, the Plan 9 grew to be a beautiful young
maid herself.  She had far fewer suitors than the Unix had once
enjoyed, since she was competing with the Unix imitators.  Even so, a
small but faithful group of savants admired her, dazzled by the grace
and civility the Unix had taught her."

(Thanks, Russ!)
--Joel

Re: [9fans] Glendix?

[John Stalker]

> I picked this idea from the GSoC07 Wiki page: porting the Plan 9
> userspace to the Linux kernel.

For your own sanity I would suggest that you consider a NetBSD base
rather than a Linux base.  You get most of the portability and you
get a much better thought out binary emulation layer.  It's also
a lot less ugly, which will matter a lot as you need to read and
modify a fair amount of code.  You should be able to run both
native and plan9 binaries, unmodified, side by side if you do things
right.  You should even be able to run NetBSD apps in X on one virtual
terminal and plan9 apps, of which there are sadly very few, in rio
on another virtual terminal.

-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] Glendix?

[Harri Haataja]

On Tue, Nov 13, 2007 at 01:30:24PM +0000, John Stalker wrote:
> > I picked this idea from the GSoC07 Wiki page: porting the Plan 9
> > userspace to the Linux kernel.
> For your own sanity I would suggest that you consider a NetBSD base
> rather than a Linux base.  You get most of the portability and you
> get a much better thought out binary emulation layer. 

> You should be able to run both
> native and plan9 binaries, unmodified, side by side if you do things
> right.

Isn't there also an "emulator" for Linux binaries on the
same arch (nearly always x86 if we think in binaries).

Another thing is, if you could get NetBSD to look like plan9,
maybe you would get this Glendix on all (or even some) of the
hw architectures the "world's most portable operating system"
supports!

-- 
To know what you prefer, instead of humbly saying Amen
to what the world tells you you ought to prefer,
is to have kept your soul alive.
	-- Robert Louis Stevenson

Re: [9fans] Glendix?

[John Stalker]

> Isn't there also an "emulator" for Linux binaries on the
> same arch (nearly always x86 if we think in binaries).

Yes, and also SVR4, HPUX, BSDI, SCO, Solaris, Irix, Ultrix,
and Amiga Unix binaries.  They aren't, strictly speaking,
emulators, though.  The idea is that exec determines the
type of the binary and then when the process makes a syscall
the kernel sends it to the appropriate handler for that ABI.
There is a mechanism for making each ABI see a slightly
different view of the file system so the binaries see an
environment more like the one they are expecting.

See: http://www.netbsd.org/docs/compat.html

> Another thing is, if you could get NetBSD to look like plan9,
> maybe you would get this Glendix on all (or even some) of the
> hw architectures the "world's most portable operating system"
> supports!

Yes, it would allow you to run plan9 binaries on a toaster, if
you port kencc to the TS-7200 architecture.
-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] Glendix?

[Aki Nyrhinen]

On Nov 13, 2007 6:22 PM, John Stalker <stalker@maths.tcd.ie> wrote:
> Yes, it would allow you to run plan9 binaries on a toaster, if
> you port kencc to the TS-7200 architecture.

no need to port anything. plan9 runs on ts7200 native.

Re: [9fans] Glendix?

[Uriel]

That would make sense if NetBSD had private namespaces and 9P support.
(There is a userspace
9P driver now using puffs, but I'm not sure how well it works, and
v9fs is much more widely used). Not to mention
that if you want to run lunix software, linux is the best option by
far (in other words, if you want to run software that sucks, you need
an OS that sucks properly, BSDs suck at sucking ;P)).

In any case, I think private namespaces are the dealbreaker, if you
want a Plan 9 environment, you need a kernel with private namespaces,
I wish the BSD people would see how important they are, but then, I
feel sorry for the VFS they have to deal with...

uriel

On Nov 13, 2007 2:30 PM, John Stalker <stalker@maths.tcd.ie> wrote:
> > I picked this idea from the GSoC07 Wiki page: porting the Plan 9
> > userspace to the Linux kernel.
>
> For your own sanity I would suggest that you consider a NetBSD base
> rather than a Linux base.  You get most of the portability and you
> get a much better thought out binary emulation layer.  It's also
> a lot less ugly, which will matter a lot as you need to read and
> modify a fair amount of code.  You should be able to run both
> native and plan9 binaries, unmodified, side by side if you do things
> right.  You should even be able to run NetBSD apps in X on one virtual
> terminal and plan9 apps, of which there are sadly very few, in rio
> on another virtual terminal.
>
> --
> John Stalker
> School of Mathematics
> Trinity College Dublin
> tel +353 1 896 1983
> fax +353 1 896 2282
>

Re: [9fans] Glendix?

[Iruata Souza]

On Nov 13, 2007 2:39 PM, Uriel <uriel99@gmail.com> wrote:
> In any case, I think private namespaces are the dealbreaker, if you
> want a Plan 9 environment, you need a kernel with private namespaces,
> I wish the BSD people would see how important they are, but then, I
> feel sorry for the VFS they have to deal with...
>
> uriel

I wish them to see that too. Feel sorry for me, then :]

Re: [9fans] Glendix?

[Charles Forsyth]

>> I wish the BSD people would see how important they are, but then, I
>> feel sorry for the VFS they have to deal with...
>>
>> uriel

really? i'd supposed the bsd vfs was better designed.  isn't it? (i hadn't really looked at it
for a years, so that wasn't rhetorical, i was really asking a question.)
the linux one has lots of things in quite the wrong place
because ... all decent files are on proper storage somewhere or they are damned!

Re: [9fans] Glendix?

[Iruata Souza]

On Nov 13, 2007 4:02 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> >> I wish the BSD people would see how important they are, but then, I
> >> feel sorry for the VFS they have to deal with...
> >>
> >> uriel
>
> really? i'd supposed the bsd vfs was better designed.  isn't it? (i hadn't really looked at it
> for a years, so that wasn't rhetorical, i was really asking a question.)
> the linux one has lots of things in quite the wrong place
> because ... all decent files are on proper storage somewhere or they are damned!
>

since I'm writing o9fs for OpenBSD I've been dealing with it's VFS for
the last months... the little I've read of linux VFS makes me thing
BSD ones are easy stuff to deal with.

iru

Re: [9fans] Glendix?

[David Leimbach]

On Nov 13, 2007 10:02 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
> >> I wish the BSD people would see how important they are, but then, I
> >> feel sorry for the VFS they have to deal with...
> >>
> >> uriel
>
> really? i'd supposed the bsd vfs was better designed.  isn't it? (i hadn't really looked at it
> for a years, so that wasn't rhetorical, i was really asking a question.)
> the linux one has lots of things in quite the wrong place
> because ... all decent files are on proper storage somewhere or they are damned!
>
>

I was of the impression the Linux VFS layer was set up to work well with NFS.

I've no idea how the BSD VFS is these days.  Mac OS X had stackable
filesystems for a while, then Apple discouraged that practice
(presumably due to overheads of doing so... so goodbye original
implementation of unionfs).

DragonflyBSD was going to have a VFS based on a message passing system
of sorts... but not 9p :-).  That would make things like FUSE pretty
easy I'd think, or 9p for that matter.

FreeBSD may still allow stackable filesystems, but it's hard to tell
where they are because all the cool kids work on linux.

Dave

Re: [9fans] Glendix?

[David Leimbach]

> DragonflyBSD was going to have a VFS based on a message passing system
> of sorts... but not 9p :-).  That would make things like FUSE pretty
> easy I'd think, or 9p for that matter.
>

Not sure where they are yet but here's their idea:

http://www.dragonflybsd.org/docs/goals.shtml#vfsmodel

> Dave
>

Re: [9fans] Glendix?

[Iruata Souza]

On Nov 13, 2007 8:04 PM, David Leimbach <leimy2k@gmail.com> wrote:
> I was of the impression the Linux VFS layer was set up to work well with NFS.
>
> I've no idea how the BSD VFS is these days.  Mac OS X had stackable
> filesystems for a while, then Apple discouraged that practice
> (presumably due to overheads of doing so... so goodbye original
> implementation of unionfs).
>
OpenBSD has dropped stackable filesystems long ago. The original BSD
unionfs implementation was a nightmare. I started writing a trivial
just for the sake of learning.

> DragonflyBSD was going to have a VFS based on a message passing system
> of sorts... but not 9p :-).  That would make things like FUSE pretty
> easy I'd think, or 9p for that matter.
>

I haven't touched the VFS itself, but with o9fs (9P filesystem for
OpenBSD) one should be allow ed to write userland file servers (that's
one of my personal goals).


iru

Re: [9fans] Glendix?

[R]

On Nov 14, 2007 1:19 AM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> I haven't touched the VFS itself, but with o9fs (9P filesystem for
> OpenBSD) one should be allow ed to write userland file servers (that's
> one of my personal goals).

OpenBSD already has filesystems in userland. Look for mount_xfs
(nothing to do with the SGI/linux thing). It is used by their afs client
implementation.

Re: [9fans] Glendix?

[Iruata Souza]

On 11/14/07, R <0xef967c36@gmail.com> wrote:
> OpenBSD already has filesystems in userland. Look for mount_xfs
> (nothing to do with the SGI/linux thing). It is used by their afs client
> implementation.
>

if you talking about /sbin/mount_xfs, it's just a mounter for the xfs
filesystem. if you take a look at /sys/xfs you'll see what have to be
done in the kernel.
o9fs is the only thing residing in the kernel in my case. the userland
filesystem/fileserver could be written entirely in userland with
lib9pclient or libixp.

iru

Re: [9fans] Glendix?

[R]

On Nov 14, 2007 1:44 PM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> On 11/14/07, R <0xef967c36@gmail.com> wrote:
> > OpenBSD already has filesystems in userland. Look for mount_xfs
> > (nothing to do with the SGI/linux thing). It is used by their afs client
> > implementation.
> >
>
> if you talking about /sbin/mount_xfs, it's just a mounter for the xfs
> filesystem. if you take a look at /sys/xfs you'll see what have to be
> done in the kernel.

No, you're wrong !

You can write a new filesystem as a userland daemon - and have
it communicate with the kernel via a /dev/xfs* device.
There's no need for extra code in the kernel.

In fact, that's exactly how afsd (the Andrew Filesystem client, part
of the standard distribution) is working.

This has become off-topic here, I excuse myself to other people
not interested in OpenBSD details, etc ;-)

Re: [9fans] Glendix?

[Christian Kellermann]

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

* R <0xef967c36@gmail.com> [071114 13:19]:
> On Nov 14, 2007 1:44 PM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> > On 11/14/07, R <0xef967c36@gmail.com> wrote:
> > > OpenBSD already has filesystems in userland. Look for mount_xfs
> > > (nothing to do with the SGI/linux thing). It is used by their afs client
> > > implementation.
> > >
> >
> > if you talking about /sbin/mount_xfs, it's just a mounter for the xfs
> > filesystem. if you take a look at /sys/xfs you'll see what have to be
> > done in the kernel.
> 
> No, you're wrong !
> 
> You can write a new filesystem as a userland daemon - and have
> it communicate with the kernel via a /dev/xfs* device.
> There's no need for extra code in the kernel.
> 
> In fact, that's exactly how afsd (the Andrew Filesystem client, part
> of the standard distribution) is working.

You are both right. The AFS daemon runs in userspace. There has to be
a kernel interface to get it into the systems namespace facility
(here it is called VFS). For AFS this interface is very application specific 
(/dev/xfs) but Iru's approach would allow to write drivers in userspace and
communicate with the kernel through an application independent interface.

This is what 9p is all about...

-- 
You may use my gpg key for replies:
pub  1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] Glendix?

[R]

On Nov 14, 2007 2:40 PM, Christian Kellermann
<Christian.Kellermann@nefkom.net> wrote:
> You are both right. The AFS daemon runs in userspace. There has to be
> a kernel interface to get it into the systems namespace facility
> (here it is called VFS). For AFS this interface is very application specific
> (/dev/xfs) but Iru's approach would allow to write drivers in userspace and

It's a generic interface, not application specific and  not tied to AFS
peculiarities.
Think FUSE, only with using character devices instead of unix sockets
to communicate with the userland.

> communicate with the kernel through an application independent interface.
>
> This is what 9p is all about...

Re: [9fans] Glendix?

[Christian Kellermann]

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

* R <0xef967c36@gmail.com> [071114 14:04]:
> Think FUSE, only with using character devices instead of unix sockets
> to communicate with the userland.

indeed. My apologies.
-- 
You may use my gpg key for replies:
pub  1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] Glendix?

[John Stalker]

> That would make sense if NetBSD had private namespaces and 9P support.

I think this is fixable without enormous effort if you are willing
to let the BSD applications lose most of the benefits of having
plan9 around.  The way ABI emulation works you need to intercept
system calls in any case and, as I noted before, the emulators NetBSD
already has catch calls to open and show them a modified hierarchy.
It would not be too difficult to make that modified hierarchy
potentially different for each process.  What you lose is that only
plan9 applications would get the benefits of private name spaces,
not native applications.  Still, you would get something a lot better
than running plan9 under qemu in a virtual terminal, which is what
I find myself doing a lot lately.

-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] Glendix?

[Russ Cox]

> 1) Modify the Linux kernel to present a 9P interface to itself (too
> hard, almost like re-writing several important parts of the kernel)
> 2) Modify the Plan 9 userspace to work with POSIX (Yuck, and Plan9Port
> already does this)
> 3) Create a custom INIT process which will be responsible for providing
> all the "plan 9 kernelish" features that userspace programs expect (for
> eg. providing the /net directory), so that all of them can run unmodified.

As Forsyth says, this may not be such a great final-year project,
especially if you have only two months in which to do the work.

That said again, I don't think any of the three strategies above would
really make Linux feel like Plan 9.  For example, I should be able to
"9fs sources" and then run the Unix ls or the Gnome file browser
or whatever on /n/sources and have it work.

To really make it feel like Plan 9, you'd first want to write a binary
format driver (in Linux) for Plan 9's a.out binaries.  Then you can
load Plan 9 binaries directly.  That much is pretty simple.

Next, you'd want to implement the Plan 9 system calls as an "alternate
personality" for the Linux kernel, to be used when running the Plan 9
binaries.  Some of the system calls are fairly easy -- open, read, write,
close, stat, wstat -- but bind / mount will require:

  - per-process name spaces accessible to normal users
    (CLONE_NEWNS is only available to root, but you can
    probably reuse some or all of the code)

  - letting normal users do 9p mounts anywhere in their
    own name space (can probably use v9fs here)

Also rfork, notes, etc. will require a little bit of work,
but they're straightforward.

Once you've got that, then the icing on the cake would be doing
things like writing a /net for Linux and then rewriting the socket
calls to do user space file operations on /net.  Then you could 
do things like

  import othermachine /net
  firefox

Also the missing /proc files and so on.

Russ

Re: [9fans] Glendix?

[Charles Forsyth]

> As Forsyth says, this may not be such a great final-year project,
> especially if you have only two months in which to do the work.

he's got 4 months but my suggestion was therefore to go for something
that `should' take 2 (or 3 at most) on the grounds that the time required
usually increases.  sadly.

Re: [9fans] Glendix?

[Latchesar Ionkov]

I agree. Trying to do this in 4 months will end up as one of the too
many unfinished Plan9 related projects.

    Lucho

On Nov 13, 2007 9:42 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
> > As Forsyth says, this may not be such a great final-year project,
> > especially if you have only two months in which to do the work.
>
> he's got 4 months but my suggestion was therefore to go for something
> that `should' take 2 (or 3 at most) on the grounds that the time required
> usually increases.  sadly.
>
>

Re: [9fans] Glendix?

[ron minnich]

On Nov 13, 2007 9:44 AM, Latchesar Ionkov <lucho@gmx.net> wrote:
> I agree. Trying to do this in 4 months will end up as one of the too
> many unfinished Plan9 related projects.

yep, We have too many of those.

We could use help in making THNX a really solid environment, if anyone
is interested.

There are a bunch of half-finished projects in Plan 9, and it would
make sense to go toward finishing them, rather than starting another
half-finished project.

Sorry to be discouraging. But part of learning is seeing the
difference between "works sometimes" and "finished project". The rule
is true: 80% of the work is in the last 20% of the project. Or worse.

ron

[9fans] Nine4Linux [WAS: Glendix?]

[Enrico Weigelt]

* Anant Narayanan <anant@kix.in> wrote:

Hi folks,

just a few thoughts about that issue: 

I think the best approach for supplying an plan9 environment 
on an Linux kernel can be done completely in userland, maybe 
utilize some kernel parts (local namespaces, etc), a little
bit like usermode-linux/coLinux or Oberon4Linux work.

* an special libc, which provides an Plan9-API (instead GNU)
  (uclibc could be a good starting point)
* GCC can be reusused, all builds work in an sysroot'ed 
  cross-environment.
* the p9-libc could either do 9P handling completely by itself
  or use v9fs (depending on system configuration). 
* setting up v9fs and local namespaces for unprivileged users
  could be done by an separate server, maybe with some bit 
  additional kernel support
* for better performance, some special filesystems (eg /net
  or /draw) could be implemented either inside p9libc or 
  maybe as an special kernel filesystem.


To get started, maybe some of you p9 gurus could provide me
some example source for for p9 applications, and I'll try to
get uclibc tweaked to make it source-compatible.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] Nine4Linux [WAS: Glendix?]

[erik quanstrom]

have you seen p9p (http://swtch.com/plan9port)?

- erik

Re: [9fans] Nine4Linux [WAS: Glendix?]

[Enrico Weigelt]

* erik quanstrom <quanstro@quanstro.net> wrote:
> have you seen p9p (http://swtch.com/plan9port)?

Yes, but I'm not yet sure if this is really what I have in mind.
But at least its a good step in that direction.

I'm intending to trim down uclibc and maybe put the p9p base 
library stuff (9P handling, etc) there. This should save us 
the glibc overhead.

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] Nine4Linux [WAS: Glendix?]

[Paweł Lasek]

On Nov 22, 2007 7:01 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * erik quanstrom <quanstro@quanstro.net> wrote:
> > have you seen p9p (http://swtch.com/plan9port)?
>
> Yes, but I'm not yet sure if this is really what I have in mind.
> But at least its a good step in that direction.
>
> I'm intending to trim down uclibc and maybe put the p9p base
> library stuff (9P handling, etc) there. This should save us
> the glibc overhead.

It could be beneficial to talk with the guys behind RSBAC (
http://www.rsbac.org ).
While their security model may differ from Plan 9's, their framework should be a
fine tool to add proper semantics, like allowing everybody to have
custom namespaces
or Plan9 capabilities. After all, their system IIRC discards the whole
security mechanism
from Unix supplying different modules to create whatever policy you want.

And glibc should be damned. IMHO, the main library in the system
should be a library written for
that OS, not some "multi-platform" thingy designed for different
system than its main use :p

> cu
> --
> ---------------------------------------------------------------------
>  Enrico Weigelt    ==   metux IT service - http://www.metux.de/
> ---------------------------------------------------------------------

-- 
Paul Lasek