mostly section 4 of the manual, i'd have said,
although there are a few in section 8 where the
file service is incidental to the service
(eg, cs and dns)

of course, that's just the protocol, and to show the larger
idea of the representation of things by name spaces
(instead of ioctls and special system calls)
would have to include section 3 (devices).

it's fairly pervasive.

FUSE won. It's easy, it works, and it has cross-platform support (macos/linux).

9p is not going to replace fuse now, if ever, on these systems.

That's not to say that 9p goes away. But it's not worth worrying about
whether FUSE will have more users -- it already has and it probably
always will.

That said, what's the "resource sharing protocol" for fuse? None of
those file systems has a common wire protocol AFAICT. Those servers
are hooks from kernel to user to "something". FUSE is not for resource
sharing, is it? It's for making it easy to write file systems for
Linux users.

ron

and what's at the end of a fuse?
exactly. i was reminded of that the other night as
i was lighting the blue touch paper before standing WELL BACK

> That said, what's the "resource sharing protocol" for fuse? None of
> those file systems has a common wire protocol AFAICT. Those servers
> are hooks from kernel to user to "something". FUSE is not for resource
> sharing, is it? It's for making it easy to write file systems for
> Linux users.

the new rangboom agents include 9pfuse (brucee's work based on russ'
p9p code) and run on linux and mac os x. i was hoping to release them
by the end of oct (in time for iwp9). filesystems imported from plan9 are
mounted as fuse fs. fuse has a lot of quirks and doesn't inspire confidence.

On Fri, Nov 7, 2008 at 3:45 PM, Skip Tavakkolian <9nut@9netics.com> wrote:
> fuse has a lot of quirks and doesn't inspire confidence.

Which hasn't stopped most of the software I am abused by -- er, use --
from achieving world dominance :-)

ron

On Fri, 2008-11-07 at 22:38 +0000, C H Forsyth wrote:
> of course, that's just the protocol, and to show the larger
> idea of the representation of things by name spaces
> (instead of ioctls and special system calls)
> would have to include section 3 (devices).
>
> it's fairly pervasive.

Sure. But that would an argument in favor of the Plan 9/Inferno
kernel architecture, not the protocol itself. Nobody's denying
that 9P is a perfect match to that kind of kernel architecture.
What I'm trying to find out is whether the protocol could stand
its own ground even if Plan9 kernel is not serving nor muxing it.

I have always used an argument of simplicity and ease of implementation.
In fact, from that point of view, 9P is better than FUSE:
http://fuse.sourceforge.net/wiki/ind...nguageBindings
vs
http://9p.cat-v.org/implementations

That's the good news, the bad news is that the "Network effect"
seems to be really working in favor of FUSE: the amount of
*already* implemented fileservers is nothing short of amazing.

Thanks,
Roman.

On Fri, 2008-11-07 at 14:31 -0800, ron minnich wrote:
> FUSE won. It's easy, it works, and it has cross-platform support (macos/linux).

It certainly looks that way. It also certainly looks like I have to
study it. Do you guys have any good pointers and/or wisdom in that
department? I'd be happy to take answers off the list, btw.

> 9p is not going to replace fuse now, if ever, on these systems.
>
> That's not to say that 9p goes away. But it's not worth worrying about
> whether FUSE will have more users -- it already has and it probably
> always will.

Fair enough. But that begs the next question: realistically speaking,
what is the right area for 9P to be used these days? Where would it
be the perfect fit in cases where Plan9/Inferno are not there to
leverage it?

> That said, what's the "resource sharing protocol" for fuse?

Are you talking about this:
http://fuse.sourceforge.net/wiki/ind...ProtocolSketch
It is riddled with POSIX inspired quirks as far as I can
tell but given enough thrust this particular pig surely can be
made airborne. Or so it appears after an hour or so of cursory
read ;-)

> None of those file systems has a common wire protocol AFAICT. Those servers
> are hooks from kernel to user to "something". FUSE is not for resource
> sharing, is it? It's for making it easy to write file systems for
> Linux users.

That depends on the point of view: very few things talk 9P natively,
most of the resource sharing is done via a hoge-podge of protocols
that, unfortunately, already exist. I wish I had control over the
server *and* the client in which case 9P would be a perfect fit.
But I don't. I have to hook up with what's already there.

And FUSE, as I realize now, seems to fit the bill quite nicely.
It is available on quite a few OSes and the list of resource sharing
protocols for which adapters are already available seems to be quite
large.

Thanks,
Roman.

On Fri, Nov 7, 2008 at 7:43 PM, Roman V. Shaposhnik wrote:

> Are you talking about this:
> http://fuse.sourceforge.net/wiki/ind...ProtocolSketch

That's just kernel to user on same machine. What goes over the wire?

> And FUSE, as I realize now, seems to fit the bill quite nicely.
> It is available on quite a few OSes and the list of resource sharing
> protocols for which adapters are already available seems to be quite
> large.

And little lacks in 9p like symlnks, xatrr, etc. are a killer.

ron

On Nov 7, 2008, at 7:56 PM, ron minnich wrote:
>> And FUSE, as I realize now, seems to fit the bill quite nicely.
>> It is available on quite a few OSes and the list of resource sharing
>> protocols for which adapters are already available seems to be quite
>> large.
>
> And little lacks in 9p like symlnks, xatrr, etc. are a killer.


Not really no. At least not for the kind of things I care about
at the moment. Like enabling mounts to the source code
repositories and such.

Thanks,
Roman.

Indeed. Fortunately Russ' code was very clean, but if you turn on
tracing you get quite a surprise. Here we are concerned about
optimizing 9p. The amount of fuse traffic for simple operations is
astounding. You stop wondering "why?" and just try and cope. I'm not
dumping on fuse - it does fill a gap - rather I just don't wish to
look at its implementation.

brucee

On Sat, Nov 8, 2008 at 1:45 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>> That said, what's the "resource sharing protocol" for fuse? None of
>> those file systems has a common wire protocol AFAICT. Those servers
>> are hooks from kernel to user to "something". FUSE is not for resource
>> sharing, is it? It's for making it easy to write file systems for
>> Linux users.
>
> the new rangboom agents include 9pfuse (brucee's work based on russ'
> p9p code) and run on linux and mac os x. i was hoping to release them
> by the end of oct (in time for iwp9). filesystems imported from plan9 are
> mounted as fuse fs. fuse has a lot of quirks and doesn't inspire confidence.
>
>
>

> The amount of fuse traffic for simple operations is
> astounding. You stop wondering "why?" and just try and cope. I'm not
> dumping on fuse - it does fill a gap - rather I just don't wish to
> look at its implementation.

This sound so much like the argument about shared libraries ...

>> 9p is not going to replace fuse now, if ever, on these systems.
>>
>> That's not to say that 9p goes away. But it's not worth worrying about
>> whether FUSE will have more users -- it already has and it probably
>> always will.

if the winner is determined by usage (silly criteria, i think), the
winner is not FUSE. the winner is email, by whatever protocol's
handy.

- erik

> Sure. But that would an argument in favor of the Plan 9/Inferno
> kernel architecture, not the protocol itself. Nobody's denying
> that 9P is a perfect match to that kind of kernel architecture.
> What I'm trying to find out is whether the protocol could stand
> its own ground even if Plan9 kernel is not serving nor muxing it.

this depends entirely on your criteria and constraints.

- erik

It seems that MS is pushing webdav hard.

On Sat, Nov 8, 2008 at 12:47 PM, erik quanstrom wrote:
>> Sure. But that would an argument in favor of the Plan 9/Inferno
>> kernel architecture, not the protocol itself. Nobody's denying
>> that 9P is a perfect match to that kind of kernel architecture.
>> What I'm trying to find out is whether the protocol could stand
>> its own ground even if Plan9 kernel is not serving nor muxing it.
>
> this depends entirely on your criteria and constraints.
>
> - erik
>
>
>

>It seems that MS is pushing webdav hard.

that's what's needed when heavy things run out of fuel.

>>It seems that MS is pushing webdav hard.
>
> that's what's needed when heavy things run out of fuel.

to paraphrase Edison, MS' genius is 1% development and 99% marketing.

And don't forget MS' programming motto, 'Don't think; Type!'

On Nov 8, 2008, at 12:21 PM, Skip Tavakkolian wrote:

>>> It seems that MS is pushing webdav hard.
>>
>> that's what's needed when heavy things run out of fuel.
>
> to paraphrase Edison, MS' genius is 1% development and 99% marketing.
>
>
>

Well, they do have a branch called "MicroSoft Research" that they seem
fond of putting money into. And apparently, a portion of that has
gone into making an Inferno/Plan 9 -equivalent, thus far dubbed, "MS
Singularity". Development has been going on for quite some time, it
seems. Think it'll outweigh what we have going with Plan 9?