On Sun, Nov 25, 2018 at 10:04:55PM -0500, Jan Harkes wrote:
> Without extensions, you only get access to files and directories, enough
> to recover some data from Coda in an emergency but probably not for
> general purpose usage. But the specification is extensible and with Unix
> and Linux extensions there are symlinks. I initially implemented some
> read-only basic functionality and Alexandra Snoy took this and added
> read-write functionality and implemented support for both Unix and Linux
> 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?

> The same way we fake a realm mountpoint when we look up a name that
> looks like a domain name that happens to have a Coda server running, we
> create a temporary file that only exists in the local cache if it is
> opened with a special name. We then write the pioctl 'request' to the
> file and close it. Only the user who created the file can reopen it for
> reading, and if it isn't opened it will eventually get dropped from the
> cache, but when it is opened for reading the actual pioctl 'upcall' is
> triggered and the result is written back into the file before the open
> returns.

Nice!

> 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).

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
real pioctl. (The wordsize-specific mount call in Venus remains of
course an obstacle, unless it becomes implemented in the kernel along
the other ia32-syscalls)

> And... the last couple released versions already included this support,
> so your client may already be using pioctls through temporary files
> without actually going through the Coda kernel module's pioctl handler.

That's a good news. Congratulations!

> 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?

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?)

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

Regards,
Rune