[9fans] P9p's mount(1) on linux

[9fans] P9p's mount(1) on linux

[Uriel]

Here is a tinny patch to make p9p's mount(1) work on linux even if you
have the v9fs (or fuse *yuck*) modules built into your kernel rather
than as modules.

Still there is the issue of what to do if you are not root, maybe a
9pmount helper program that is suid could take care of this? Sqweek
wrote a very nice 9mount program (
http://sqweek.dnsdojo.org/code/9mount/docs )  that maybe could be
added to p9p, unfortunately v9fs has changed its interface/params once
more and 9mount doesn't work with recent kernels *sigh*

Peace and best wishes

uriel

P.S.: Can someone please forward this to russ, last I heard he had my
email address in his kilfile.

diff -r fe7a4a762f75 bin/mount
--- a/bin/mount Sun Jun 15 01:46:23 2008 -0400
+++ b/bin/mount Thu Jun 19 03:41:08 2008 +0200
@@ -6,12 +6,12 @@
 }
 switch(`{uname}){
 case Linux
-       if(lsmod|9 grep -si '^9p(2000)? '){
+       if(cat /proc/filesystems|9 grep -si '   9p(2000)?$'){
                if(u test -S $1)
                        exec u mount -t 9p -o proto'='unix,name'='$USER $1 $2
                exec u mount -t 9p -o proto'='tcp,name'='$USER $1 $2
        }
-       if(lsmod|9 grep -si '^fuse ')
+       if(cat /proc/filesystems|9 grep -si '   fuse$')
                exec 9pfuse $1 $2
        echo 'don''t know how to mount (no 9p, no fuse)' >[1=2]
 case FreeBSD

Re: [9fans] P9p's mount(1) on linux

[Eric Van Hensbergen]

because I'm difficult you may need to check the version of the kernel
you are running, some of the options syntax has changed and you may
want to set some of the newer security options (the access option) to
be more consistent with the Plan 9 mindset.

     -eric

On Wed, Jun 18, 2008 at 8:42 PM, Uriel <uriel99@gmail.com> wrote:
> Here is a tinny patch to make p9p's mount(1) work on linux even if you
> have the v9fs (or fuse *yuck*) modules built into your kernel rather
> than as modules.
>
> Still there is the issue of what to do if you are not root, maybe a
> 9pmount helper program that is suid could take care of this? Sqweek
> wrote a very nice 9mount program (
> http://sqweek.dnsdojo.org/code/9mount/docs )  that maybe could be
> added to p9p, unfortunately v9fs has changed its interface/params once
> more and 9mount doesn't work with recent kernels *sigh*
>
> Peace and best wishes
>
> uriel
>
> P.S.: Can someone please forward this to russ, last I heard he had my
> email address in his kilfile.
>
> diff -r fe7a4a762f75 bin/mount
> --- a/bin/mount Sun Jun 15 01:46:23 2008 -0400
> +++ b/bin/mount Thu Jun 19 03:41:08 2008 +0200
> @@ -6,12 +6,12 @@
>  }
>  switch(`{uname}){
>  case Linux
> -       if(lsmod|9 grep -si '^9p(2000)? '){
> +       if(cat /proc/filesystems|9 grep -si '   9p(2000)?$'){
>                if(u test -S $1)
>                        exec u mount -t 9p -o proto'='unix,name'='$USER $1 $2
>                exec u mount -t 9p -o proto'='tcp,name'='$USER $1 $2
>        }
> -       if(lsmod|9 grep -si '^fuse ')
> +       if(cat /proc/filesystems|9 grep -si '   fuse$')
>                exec 9pfuse $1 $2
>        echo 'don''t know how to mount (no 9p, no fuse)' >[1=2]
>  case FreeBSD
>
>

Re: [9fans] P9p's mount(1) on linux

[Uriel]

Thanks for your reply, but I'm not clear what you mean: should p9p's
mount check the kernel version? or are you talking about 9mount?

By the way, where can one find the git tree with the latest v9fs? I
was googling and struggling with the swik 'thing' (words fail me...),
but couldn't find it, I know it is somewhere...

Also any other feedback on what changes and improvements 9mount might
need before it can be made part of p9p (or maybe shipped with the
standard linux mount(1) tools?).

uriel

On Thu, Jun 19, 2008 at 3:57 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> because I'm difficult you may need to check the version of the kernel
> you are running, some of the options syntax has changed and you may
> want to set some of the newer security options (the access option) to
> be more consistent with the Plan 9 mindset.
>
>     -eric
>
> On Wed, Jun 18, 2008 at 8:42 PM, Uriel <uriel99@gmail.com> wrote:
>> Here is a tinny patch to make p9p's mount(1) work on linux even if you
>> have the v9fs (or fuse *yuck*) modules built into your kernel rather
>> than as modules.
>>
>> Still there is the issue of what to do if you are not root, maybe a
>> 9pmount helper program that is suid could take care of this? Sqweek
>> wrote a very nice 9mount program (
>> http://sqweek.dnsdojo.org/code/9mount/docs )  that maybe could be
>> added to p9p, unfortunately v9fs has changed its interface/params once
>> more and 9mount doesn't work with recent kernels *sigh*
>>
>> Peace and best wishes
>>
>> uriel
>>
>> P.S.: Can someone please forward this to russ, last I heard he had my
>> email address in his kilfile.
>>
>> diff -r fe7a4a762f75 bin/mount
>> --- a/bin/mount Sun Jun 15 01:46:23 2008 -0400
>> +++ b/bin/mount Thu Jun 19 03:41:08 2008 +0200
>> @@ -6,12 +6,12 @@
>>  }
>>  switch(`{uname}){
>>  case Linux
>> -       if(lsmod|9 grep -si '^9p(2000)? '){
>> +       if(cat /proc/filesystems|9 grep -si '   9p(2000)?$'){
>>                if(u test -S $1)
>>                        exec u mount -t 9p -o proto'='unix,name'='$USER $1 $2
>>                exec u mount -t 9p -o proto'='tcp,name'='$USER $1 $2
>>        }
>> -       if(lsmod|9 grep -si '^fuse ')
>> +       if(cat /proc/filesystems|9 grep -si '   fuse$')
>>                exec 9pfuse $1 $2
>>        echo 'don''t know how to mount (no 9p, no fuse)' >[1=2]
>>  case FreeBSD
>>
>>
>
>

Re: [9fans] P9p's mount(1) on linux

[Rodolfo kix García]

In my opinion,

the Uriel patch is better. If you check for the words "9p(2000)" and
"fuse" (without spaces, end of line, start of line, or other things)
probably the patch will be "kernel independent"

The "lsmod" output format can change in new releases too.

Saludos.

> Thanks for your reply, but I'm not clear what you mean: should p9p's
> mount check the kernel version? or are you talking about 9mount?
>
> By the way, where can one find the git tree with the latest v9fs? I
> was googling and struggling with the swik 'thing' (words fail me...),
> but couldn't find it, I know it is somewhere...
>
> Also any other feedback on what changes and improvements 9mount might
> need before it can be made part of p9p (or maybe shipped with the
> standard linux mount(1) tools?).
>
> uriel
>
> On Thu, Jun 19, 2008 at 3:57 AM, Eric Van Hensbergen <ericvh@gmail.com>
> wrote:
>> because I'm difficult you may need to check the version of the kernel
>> you are running, some of the options syntax has changed and you may
>> want to set some of the newer security options (the access option) to
>> be more consistent with the Plan 9 mindset.
>>
>>     -eric
>>
>> On Wed, Jun 18, 2008 at 8:42 PM, Uriel <uriel99@gmail.com> wrote:
>>> Here is a tinny patch to make p9p's mount(1) work on linux even if you
>>> have the v9fs (or fuse *yuck*) modules built into your kernel rather
>>> than as modules.
>>>
>>> Still there is the issue of what to do if you are not root, maybe a
>>> 9pmount helper program that is suid could take care of this? Sqweek
>>> wrote a very nice 9mount program (
>>> http://sqweek.dnsdojo.org/code/9mount/docs )  that maybe could be
>>> added to p9p, unfortunately v9fs has changed its interface/params once
>>> more and 9mount doesn't work with recent kernels *sigh*
>>>
>>> Peace and best wishes
>>>
>>> uriel
>>>
>>> P.S.: Can someone please forward this to russ, last I heard he had my
>>> email address in his kilfile.
>>>
>>> diff -r fe7a4a762f75 bin/mount
>>> --- a/bin/mount Sun Jun 15 01:46:23 2008 -0400
>>> +++ b/bin/mount Thu Jun 19 03:41:08 2008 +0200
>>> @@ -6,12 +6,12 @@
>>>  }
>>>  switch(`{uname}){
>>>  case Linux
>>> -       if(lsmod|9 grep -si '^9p(2000)? '){
>>> +       if(cat /proc/filesystems|9 grep -si '   9p(2000)?$'){
>>>                if(u test -S $1)
>>>                        exec u mount -t 9p -o proto'='unix,name'='$USER
>>> $1 $2
>>>                exec u mount -t 9p -o proto'='tcp,name'='$USER $1 $2
>>>        }
>>> -       if(lsmod|9 grep -si '^fuse ')
>>> +       if(cat /proc/filesystems|9 grep -si '   fuse$')
>>>                exec 9pfuse $1 $2
>>>        echo 'don''t know how to mount (no 9p, no fuse)' >[1=2]
>>>  case FreeBSD
>>>
>>>
>>
>>
>
>


-- 
Rodolfo García AKA kix
http://www.kix.es/
EA4ERH (@IN80ER)

Re: [9fans] P9p's mount(1) on linux

[Iruata Souza]

http://swtch.com/v9fs seems to have a nightly updated copy of v9fs in
the linux kernel tree.

On Thu, Jun 19, 2008 at 12:05 AM, Uriel <uriel99@gmail.com> wrote:
> Thanks for your reply, but I'm not clear what you mean: should p9p's
> mount check the kernel version? or are you talking about 9mount?
>
> By the way, where can one find the git tree with the latest v9fs? I
> was googling and struggling with the swik 'thing' (words fail me...),
> but couldn't find it, I know it is somewhere...
>
> Also any other feedback on what changes and improvements 9mount might
> need before it can be made part of p9p (or maybe shipped with the
> standard linux mount(1) tools?).
>
> uriel
>
> On Thu, Jun 19, 2008 at 3:57 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>> because I'm difficult you may need to check the version of the kernel
>> you are running, some of the options syntax has changed and you may
>> want to set some of the newer security options (the access option) to
>> be more consistent with the Plan 9 mindset.
>>
>>     -eric
>>
>> On Wed, Jun 18, 2008 at 8:42 PM, Uriel <uriel99@gmail.com> wrote:
>>> Here is a tinny patch to make p9p's mount(1) work on linux even if you
>>> have the v9fs (or fuse *yuck*) modules built into your kernel rather
>>> than as modules.
>>>
>>> Still there is the issue of what to do if you are not root, maybe a
>>> 9pmount helper program that is suid could take care of this? Sqweek
>>> wrote a very nice 9mount program (
>>> http://sqweek.dnsdojo.org/code/9mount/docs )  that maybe could be
>>> added to p9p, unfortunately v9fs has changed its interface/params once
>>> more and 9mount doesn't work with recent kernels *sigh*
>>>
>>> Peace and best wishes
>>>
>>> uriel
>>>
>>> P.S.: Can someone please forward this to russ, last I heard he had my
>>> email address in his kilfile.
>>>
>>> diff -r fe7a4a762f75 bin/mount
>>> --- a/bin/mount Sun Jun 15 01:46:23 2008 -0400
>>> +++ b/bin/mount Thu Jun 19 03:41:08 2008 +0200
>>> @@ -6,12 +6,12 @@
>>>  }
>>>  switch(`{uname}){
>>>  case Linux
>>> -       if(lsmod|9 grep -si '^9p(2000)? '){
>>> +       if(cat /proc/filesystems|9 grep -si '   9p(2000)?$'){
>>>                if(u test -S $1)
>>>                        exec u mount -t 9p -o proto'='unix,name'='$USER $1 $2
>>>                exec u mount -t 9p -o proto'='tcp,name'='$USER $1 $2
>>>        }
>>> -       if(lsmod|9 grep -si '^fuse ')
>>> +       if(cat /proc/filesystems|9 grep -si '   fuse$')
>>>                exec 9pfuse $1 $2
>>>        echo 'don''t know how to mount (no 9p, no fuse)' >[1=2]
>>>  case FreeBSD
>>>
>>>
>>
>>
>
>



--
iru

Re: [9fans] P9p's mount(1) on linux

[Sape Mullender]

> because I'm difficult you may need to [...]
>    -eric

Amen.

Re: [9fans] P9p's mount(1) on linux

[Russ Cox]

Thanks for the patch, Uriel.


The http://swtch.com/v9fs script stopped working
a long time ago, and I never bothered to find
out why.  I've changed the text on that page,
though clicking on the "date and checksums"
link has always shown that the last update
was October 2006.


A few p9p programs--acme, tapefs, vacfs--now
accept a -m option directing them to mount at a
particular place in the directory tree, via 9pfuse.
There is no option to mount via the Linux 9p module.


I'm a little tired of the "Fuse sucks" meme.

The fuse libraries are not so great, but the fuse kernel
interface is completely reasonable, and arguably
a better fit for Unix than 9P is.  A lot of the hard work and
churn in Eric's code is because he's trying to do a good
translation from 9P to Unix VFS.  Fuse lets the
individual file servers take care of that, which is fine
with me.  Also, the FUSE kernel interface, in my
experience, has been a bit more solid and certainly
changes less often.

I think that Fuse gets a bad rap mainly because the
people using it to write file servers don't do a good job.
I've never run into bugs in the fuse kernel driver itself.
User-level file servers are an entirely new concept for
most people (present company excluded), so it's not
surprising that most of the people out there writing
user-level file servers don't fully understand the issues
in what they're implementing.  But the Fuse kernel
developers do.

I wrote a new user-level file server a month ago,
something I hadn't done in years, and I did it on Linux,
using lib9p backed by 9pfuse.  It was an entirely pleasant
experience.


Russ

Re: [9fans] P9p's mount(1) on linux

[Eric Van Hensbergen]

On Wed, Jun 18, 2008 at 10:05 PM, Uriel <uriel99@gmail.com> wrote:
> Thanks for your reply, but I'm not clear what you mean: should p9p's
> mount check the kernel version? or are you talking about 9mount?
>

Whatever function deals with passing the options to the mount system
call needs the modification.  The few changes that are there may be
fixed by me doing a better job and supporting old names for options,
but it won't help for the kernels already in circulation.

> By the way, where can one find the git tree with the latest v9fs? I
> was googling and struggling with the swik 'thing' (words fail me...),
> but couldn't find it, I know it is somewhere...

The "latest" is in linus' head branch on kernel.org.
The current development stream is in
git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git in the
v9fs-devel branch.

However, (because I am difficult) I have been reorganizing the code
base somewhat after my experiences with implementing the virtio
transport.  That code is still in-progress and is in the reorg branch
of the v9fs git tree.  My intention is to wrap that reorganization up
and get it out for review in the next week or so.

         -eric

> Also any other feedback on what changes and improvements 9mount might
> need before it can be made part of p9p (or maybe shipped with the
> standard linux mount(1) tools?).

I'll take a look today so I'm up to date on the current station and
let you know.  Basically it will probably be best to structure it as a
"mount helper" and ship it in its own package.  IIRC all the other
mount helpers (with the possible exception of NFS) ship independently.

Thanks for doing this by the way, we've need a mount helper for some
time to help smooth out some of the bumps.

            -eric

Re: [9fans] P9p's mount(1) on linux

[erik quanstrom]

>> By the way, where can one find the git tree with the latest v9fs? I
>> was googling and struggling with the swik 'thing' (words fail me...),
>> but couldn't find it, I know it is somewhere...
>
> The "latest" is in linus' head branch on kernel.org.

being unfamilar with this jargon, i initially misread this as commentary
rather than fact.

☺

- erik

Re: [9fans] P9p's mount(1) on linux

[Uriel]

> Whatever function deals with passing the options to the mount system
> call needs the modification.  The few changes that are there may be
> fixed by me doing a better job and supporting old names for options,
> but it won't help for the kernels already in circulation.

Ah, I see. Maybe just requiring a >2.6.25 kernel should be fine, or
are there going to be more changes in the future? :)

>> By the way, where can one find the git tree with the latest v9fs? I
>> was googling and struggling with the swik 'thing' (words fail me...),
>> but couldn't find it, I know it is somewhere...
>
> The "latest" is in linus' head branch on kernel.org.
> The current development stream is in
> git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git in the
> v9fs-devel branch.

Ah, that was what I was looking for, would be nice to document the
location of that repo somewhere... (*must restrain from commenting on
swik*)

> However, (because I am difficult) I have been reorganizing the code
> base somewhat after my experiences with implementing the virtio
> transport.  That code is still in-progress and is in the reorg branch
> of the v9fs git tree.  My intention is to wrap that reorganization up
> and get it out for review in the next week or so.

No worries, it is the interface changes, and releases that are broken
which are more of an issue. Hopefully we have put all that behind.

One issue that has bitten quite a few people is that v9fs uses .u by
default, which seems a really bad idea, specially given that .u will
eventually be deprecated, why not use standard 9p by default, and let
whoever wants it to enable this or that extension, that way when .l or
whatever is implemented things wont break in unexpected ways and we
can retain a sane default behavior (after all, all servers should
support plain old 9p2000 hopefully).

> I'll take a look today so I'm up to date on the current station and
> let you know.  Basically it will probably be best to structure it as a
> "mount helper" and ship it in its own package.  IIRC all the other
> mount helpers (with the possible exception of NFS) ship independently.

I see, sounds good.

> Thanks for doing this by the way, we've need a mount helper for some
> time to help smooth out some of the bumps.

All credit should go to squeek, all I have done is to do some cheering
and shouting encouragements from the sidelines.

Peace and best wishes

uriel

Re: [9fans] P9p's mount(1) on linux

[Uriel]

On Thu, Jun 19, 2008 at 5:10 PM, Russ Cox <rsc@swtch.com> wrote:
> Thanks for the patch, Uriel.
>
>
> The http://swtch.com/v9fs script stopped working
> a long time ago, and I never bothered to find
> out why.  I've changed the text on that page,
> though clicking on the "date and checksums"
> link has always shown that the last update
> was October 2006.
>
>
> A few p9p programs--acme, tapefs, vacfs--now
> accept a -m option directing them to mount at a
> particular place in the directory tree, via 9pfuse.
> There is no option to mount via the Linux 9p module.

Why not have them use p9p's mount(1)?

I wont say anything about the whole fuse debacl^h^hte, I don't think
it is productive, but in any case it would be nice if p9p still
allowed people to take advantage of v9fs when available, one of the
reasons v9fs has sucked so much in the paste is that it basically had
zero users and underwent zero testing.

Peace and best wishes.

uriel

Re: [9fans] P9p's mount(1) on linux

[sqweek]

On Thu, Jun 19, 2008 at 11:53 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> Whatever function deals with passing the options to the mount system
> call needs the modification.  The few changes that are there may be
> fixed by me doing a better job and supporting old names for options,
> but it won't help for the kernels already in circulation.

 I've just updated to 2.6.25 which means I finally had to fix 9mount
to work with the >= 2.6.24 mount options. Dealt with backwards
compatibility by simply adding both the pre AND post 2.6.24 mount
options (which was suggested by uriel or jyujin on IRC awhile back).
 So, mounting works, but v9fs's option string appears to be screwed,
which I was relying on for 9umount (to prevent unmounting things
mounted by other users). Which is not the best plan, but I'm not sure
how else to do it...

> Basically it will probably be best to structure it as a
> "mount helper" and ship it in its own package.

 I'm not sure how mount helpers work... would you have to be root to
use it that way?
-sqweek

Re: [9fans] P9p's mount(1) on linux

[sqweek]

On Thu, Jun 19, 2008 at 11:10 PM, Russ Cox <rsc@swtch.com> wrote:
> I wrote a new user-level file server a month ago,
> something I hadn't done in years, and I did it on Linux,
> using lib9p backed by 9pfuse.  It was an entirely pleasant
> experience.

 Speaking of 9pfuse - I've just pulled and the version distributed
with p9p is still not going to work on linux/x86_64. I posted a patch
for this[1], though 9fans.net doesn't appear to archive attachments -
see http://sqweek.dnsdojo.org/tmp/9pfuse.LARGEFILE.diff
 Also, I've sent you a couple of emails off-list recently about a bug
in 9p(1). I can't think of anything I might have done to offend you,
so I'm assuming they've been marked as spam or otherwise waylaid -
should I just post the patch to 9fans?
 If you did get the patch and have just been thinking about it, then
my apologies for being impatient. That scenario just seems
increasingly unlikely :)

[1] http://9fans.net/archive/2008/03/530

-sqweek

Re: [9fans] P9p's mount(1) on linux

[Eric Van Hensbergen]

On Thu, Jun 19, 2008 at 3:39 PM, sqweek <sqweek@gmail.com> wrote:
>
>  I've just updated to 2.6.25 which means I finally had to fix 9mount
> to work with the >= 2.6.24 mount options. Dealt with backwards
> compatibility by simply adding both the pre AND post 2.6.24 mount
> options (which was suggested by uriel or jyujin on IRC awhile back).
>  So, mounting works, but v9fs's option string appears to be screwed,
> which I was relying on for 9umount (to prevent unmounting things
> mounted by other users). Which is not the best plan, but I'm not sure
> how else to do it...
>

2.6.25 had some issues at release that were fixed in subsequent patches.
I've just got your bugzilla report on the option string reporting (thanks), I'll
try to get to this shortly.

>> Basically it will probably be best to structure it as a
>> "mount helper" and ship it in its own package.
>
>  I'm not sure how mount helpers work... would you have to be root to
> use it that way?
>

It would have to be setuid, at least at the moment.

           -eric

Re: [9fans] P9p's mount(1) on linux

[Eric Van Hensbergen]

>> Also any other feedback on what changes and improvements 9mount might
>> need before it can be made part of p9p (or maybe shipped with the
>> standard linux mount(1) tools?).
>
> I'll take a look today so I'm up to date on the current station and
> let you know.  Basically it will probably be best to structure it as a
> "mount helper" and ship it in its own package.  IIRC all the other
> mount helpers (with the possible exception of NFS) ship independently.
>

It looks like a really good start.  It'd be nice to have something
which supported the virtio transport as well as there is going to be
an influx of those users shortly.

Lucho had a mount helper at one time that was able to use p9p to
authenticate when necessary -- this would be a nice feature to include
in the mount helper but is difficult to include without p9p as a
dependency.

It would be nice if 9mount and/or 9bind could do an unshare to create
a new namespace, but given the current Linux semantics, I'm not sure
you can get the right behavior (ie. 9mount will have its own name
space, but then the mount won't be visible in the shell which called
it).

Some support for the loose cache would be nice, and I don't see any
way of setting larger (or smaller) msize.

Options reflecting Lucho's access option should also be incorporated
to give users some flexibility there.

Most of these are enhancements that shouldn't stand in the way of a
packaging and submission to the distros....
The only thing you need to do for them is rename the executable to
match the mount helper format (mount.9p)
and install it in /sbin.

Not sure if there are any other requirements for mount helpers, but
easy enough to test ;)  If you need additional examples look at
mount.cifs or mount.fuse -- looks like cifs has a umount helper as
well....

                -eric

Re: [9fans] P9p's mount(1) on linux

[Rob Pike]

Fuse on the Mac is markedly inferior.

-rob

Re: [9fans] P9p's mount(1) on linux

[Russ Cox]

>  Speaking of 9pfuse - I've just pulled and the version distributed
> with p9p is still not going to work on linux/x86_64. I posted a patch
> for this[1], though 9fans.net doesn't appear to archive attachments -
> see http://sqweek.dnsdojo.org/tmp/9pfuse.LARGEFILE.diff

Done.

>  Also, I've sent you a couple of emails off-list recently about a bug
> in 9p(1). I can't think of anything I might have done to offend you,
> so I'm assuming they've been marked as spam or otherwise waylaid -
> should I just post the patch to 9fans?
>  If you did get the patch and have just been thinking about it, then
> my apologies for being impatient. That scenario just seems
> increasingly unlikely :)

Done.

The patch you sent had to do with Unix signals,
so I had been putting off having to think about it.

Russ

Re: [9fans] P9p's mount(1) on linux

[Russ Cox]

>> A few p9p programs--acme, tapefs, vacfs--now
>> accept a -m option directing them to mount at a
>> particular place in the directory tree, via 9pfuse.
>> There is no option to mount via the Linux 9p module.
>
> Why not have them use p9p's mount(1)?

The code is trying to mount a file descriptor, and
the Linux 9P module provides no way to do that.
(In fact, that was the very first thing I asked for, years ago,
when I started trying to use v9fs, and to my knowledge,
it still hasn't happened.  Ron and Eric are focused on
replacing NFS, not building user-level file servers.)

I edited the code to call out to a non-existent mount9p
program before it invokes 9pfuse.  If you put a mount9p
in your path that can be invoked:

	mount9p - /mnt

to mount fd 0 onto /mnt, then the -m options will use
that instead of 9pfuse.  Perhaps one day v9fs will ship
with such a program.

Russ

Re: [9fans] P9p's mount(1) on linux

[Eric Van Hensbergen]

On Thu, Jun 19, 2008 at 6:21 PM, Russ Cox <rsc@swtch.com> wrote:
>>> A few p9p programs--acme, tapefs, vacfs--now
>>> accept a -m option directing them to mount at a
>>> particular place in the directory tree, via 9pfuse.
>>> There is no option to mount via the Linux 9p module.
>>
>> Why not have them use p9p's mount(1)?
>
> The code is trying to mount a file descriptor, and
> the Linux 9P module provides no way to do that.
> (In fact, that was the very first thing I asked for, years ago,
> when I started trying to use v9fs, and to my knowledge,
> it still hasn't happened.  Ron and Eric are focused on
> replacing NFS, not building user-level file servers.)
>

The ability to mount file descriptors has been in for a few years (at
least since 2006).  trans=fd allows you to mount from a file
descriptor (or from separate read and write file descriptors).  The
code should be functional, but it is not something which currently
gets regressed very often.

       -eric


> I edited the code to call out to a non-existent mount9p
> program before it invokes 9pfuse.  If you put a mount9p
> in your path that can be invoked:
>
>        mount9p - /mnt
>
> to mount fd 0 onto /mnt, then the -m options will use
> that instead of 9pfuse.  Perhaps one day v9fs will ship
> with such a program.
>
> Russ
>
>
>

Re: [9fans] P9p's mount(1) on linux

[Skip Tavakkolian]

> The ability to mount file descriptors has been in for a few years (at
> least since 2006).  trans=fd allows you to mount from a file
> descriptor (or from separate read and write file descriptors).  The
> code should be functional, but it is not something which currently
> gets regressed very often.

yep. rangboom agent uses v9fs this way for the imported shared ns:

	opts = smprint("noextend,%smsize=%d,name=%s,proto=fd,rfdno=%d,wfdno=%d",
			(ifsdebug?"debug=0x7,":""), 8*1024, getenv("USER"), so[1], so[1]);

Re: [9fans] P9p's mount(1) on linux

[sqweek]

On Fri, Jun 20, 2008 at 6:59 AM, Russ Cox <rsc@swtch.com> wrote:
>>  Also, I've sent you a couple of emails off-list recently about a bug
>> in 9p(1). I can't think of anything I might have done to offend you,
>> so I'm assuming they've been marked as spam or otherwise waylaid -
>> should I just post the patch to 9fans?
>>  If you did get the patch and have just been thinking about it, then
>> my apologies for being impatient. That scenario just seems
>> increasingly unlikely :)
>
> Done.
>
> The patch you sent had to do with Unix signals,
> so I had been putting off having to think about it.

 Hah, fair enough! Thanks, but I shouldn't have rushed you - the
modified patch doesn't work. writen() never returns anything less than
0. I don't really follow its purpose either - at first I thought it
was there to account for an interrupted syscall, but the
implementation differs from what I would expect for that.
-sqweek

Re: [9fans] P9p's mount(1) on linux

[sqweek]

On Fri, Jun 20, 2008 at 6:04 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> It'd be nice to have something which supported the virtio transport
>
> It would be nice if 9mount and/or 9bind could do an unshare to create
> a new namespace,
>
> Some support for the loose cache would be nice, and I don't see any
> way of setting larger (or smaller) msize.
>
> Options reflecting Lucho's access option should also be incorporated
> to give users some flexibility there.
>
> rename the executable to match the mount helper format (mount.9p)
> and install it in /sbin.

 I need to familiarise myself with these options and the mount helper
framework before I can sensibly support them. Is there any relevant
documentation I should be aware of aside from
/usr/src/linux/Documentation/filesystems/9p.txt?
 Won't happen immediately though, this weekend is free TF2 weekend and
wine 1.0 was just released :)
-sqweek

Re: [9fans] P9p's mount(1) on linux

[Eric Van Hensbergen]

On Fri, Jun 20, 2008 at 7:37 AM, sqweek <sqweek@gmail.com> wrote:
>
>  I need to familiarise myself with these options and the mount helper
> framework before I can sensibly support them. Is there any relevant
> documentation I should be aware of aside from
> /usr/src/linux/Documentation/filesystems/9p.txt?
>  Won't happen immediately though, this weekend is free TF2 weekend and
> wine 1.0 was just released :)
>

9p.txt is the most complete (which perhaps isn't saying much).
Questions (and patches to the documentation) welcome.

          -eric

Re: [9fans] P9p's mount(1) on linux

[ron minnich]

On Thu, Jun 19, 2008 at 4:04 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:

>
> Lucho had a mount helper at one time that was able to use p9p to
> authenticate when necessary -- this would be a nice feature to include
> in the mount helper but is difficult to include without p9p as a
> dependency.
>
> It would be nice if 9mount and/or 9bind could do an unshare to create
> a new namespace, but given the current Linux semantics, I'm not sure
> you can get the right behavior (ie. 9mount will have its own name
> space, but then the mount won't be visible in the shell which called
> it).

yes, the way we fixed this on 2.6.24 and clusters was that the mount
helper actually forked a shell for you as well. So you specified your
entire name space, the mount helper forked with NEWNS, and at the end
it dropped you into a shell. Not really very intuitive, but it worked
really well.

thanks

ron