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

[Uriel <uriel99@gmail.com>]

> 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