On Mon, Nov 26, 2018 at 02:21:21PM -0500, Jan Harkes wrote:
> 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.

Indeed, separate steps are much more manageable and also as long as it is
kept compatible with the old interface, the format(s) can not be changed.

However, if/when the formats are to change,
the new well specified ones (as generic protocol definitions, not
build-specific structures from .h-files) could allow to handle Venus
and its cliens like clog, cfs, repair independently from each other,
in development, deployment and maintenance.

>From the perspective of an integrator this would be a remarkable
improvement.

>From this perspective it makes also a lot of sense to be able to let
kernel, Venus and the utils all run in independent/different modes,
in the terms of the syscall set personality (e.g. *BSD vs Linux) or the
ABI (e.g. as in i386 vs x86_64 vs x32) or even the CPU (e.g. running a
binary Venus from a different CPU, wrapped in an emulator).

Again, the key is the choice of interface formats.

Ease of integration translates to more deployment.

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

Now I see which kind of uid-namespacing is necessary. Thanks Jan.

Regards,
Rune