On Mon, Nov 26, 2018 at 02:27:59PM +0100, u-x417_at_aetey.se wrote:
> On Sun, Nov 25, 2018 at 10:04:55PM -0500, Jan Harkes wrote:
> > extensions. The Unix extensions have been merged and are in recent
> > releases, I still have to pull a fix to translate fid mappings after
> > reintegration and the support for Linux extensions.
> 
> Are the extentions portable, applicable on different platforms?

My guess is that the Linux extensions probably are pretty Linux
specific, the only client that uses those that I know of is the Linux
kernel v9fs implementation.

The Unix extensions are definitely more widely supported. Here is a
list of various implementations, but I don't think it is current
because I've found some others just googling for 9pfs and fuse.

        http://9p.cat-v.org/implementations

> > And because all of this is implemented in the pioctl wrapper,
> > no pioctl using applications actually had to be changed. So this works
> > for cfs, clog, cunlog, ctokens, hoard, repair, filerepair, removeinc.
> 
> Many of them would profit from a rewrite, but I see your point (the
> magic files seem to make a rewrite easier as well, being more
> flexible than pioctl).

Yes, ideally it would be some easily parsable and human readable format,
but rewriting the way pioctls work, as well as how they are formatted
would have ended up creating far too much of a mess where nothing works.
As it is now, clients accept both the old-style pioctl upcalls as well
as file type access and the user applications and backend implementation
are unmodified.

> Possibly this can even finally work between, say ia32 venus and ia32
> cfs under a x86_64 Linux kernel, which is totally impossible with the

This was never a goal for this work.

> > So some of the things that are still needed are the pulls from Alexandra
> > to get Linux extensions merged. And we need to namespace user identities
> > so that the same user ids in different plan9 mounts don't share tokens.
> > This will probably be a bit of work because user ids are pretty much
> > everywhere.
> 
> I wonder, is/will be namespacing portable or is it mostly Linux-specific?

This is all internal to Venus, so as portable as the Coda client is.

> Is it the token-sharing with non-Coda plan9-mounts which would be bad?
> (It shouldn't? Coda tokens are pretty much unusable outside of Coda.
> Or is it some other kind of tokens you mean?)

Any application that can connect to the plan9 server socket can claim to
be any user it wants to be. So if you got tokens for local user id for
the main /coda mount, I'd prefer some incoming connection to the plan9
server that claims to be your user name or id would not gain access to
your files unless it independently provides the Coda token to prove it.

> Or do you mean multiple Coda-mounts, say in different virtualization
> domains, with separate Venus instances?

Same Venus, multiple Coda mounts, maybe different docker containers, or
virtual machines, or possibly an application with an embedded plan9
client.

Jan