Hi Jan,

Had I not known you personally and highly respected both you and your
programming skills, I would probably end up calling you a [censored]
after all the dismissive tone present in your messages.

Nevertheless, it is very valuable that you keep commenting, compared
to silence. I do appreciate hearing from you, the more objective
the better.

On Tue, Aug 05, 2014 at 12:09:18PM -0400, Jan Harkes wrote:
> before the only kernel code you would save is a: ... 123 bytes

This reflects your (incorrect) assumption about my motivation.
Please read below.

> > which would nicely move all of pioctl traffic into the upcall interface
> 
> It already _is_ in the upcall interface. A pioctl in userspace maps a
> path in Coda to a file identifier and then makes an ioctl in /coda which
> is passed to venus as an upcall. The reason we do the userspace
> path->fid mapping is because regular ioctls don't work on directories.

Well, I meant the upcall interface for regular file operations, like
open/close/stat/mkdir/... not those Coda-specific operations which are
done via cfs and ioctl.

Below are excerpts from my recent letters explaining the motivation to
get rid of the special ioctls. If my hopes are baseless or misguided
then please shed light on it:

--------------
"[incompatible mount operation]... holding back my usage of NetBSD.
The same limitation forces me currently to compile the client separately
for 32- and 64-bit kernels.
Of course the unification change will become feasible only when the pioctls
are "shortcut" past the kernel module"

"I really wish I could use the same Venus binary as long as the kernel
provides the necessary general purpose ABI. This would reduce my concrete
client maintenance burden about 3-4 times."

" Venus would only use the "portable" system calls - iff the pioctl
IPC interface is platform-independent at run time, not only at compile
time. AFAIK it is not. I do not think pioctl() can be expected to be
emulated by different implementations of Linux ABI."
--------------

What you seem to say is:  (do I interpret correctly what you mean?)

 the kernel does not have any knowledge about the format of the ioctls' data
 (in other words it is a pure "pass arbitrary data back and forth"
 interface)

This sounds good - it is a necessary but not sufficent prerequisite in the
light of the goal - to be able to let kernel, venus and cfs communicate
even when the native ABI of the kernel is different from the one of
venus and cfs - like when running venus under Linux ABI in NetBSD
or under 32-bit ABI on a 64-bit kernel.

> The ugly parts of pioctl are the binary blobs that are passed back and
> forth as requests and replies. But you are not solving that either, you

What is that makes the blobs ugly?

As long as nobody has to look inside an envelope to deliver it and as
long as the communicating parties can easily interpret the contents -
I would call it acceptable.

If the carrier has to know about the representation of data to be
delivered (say postulate that the ink must have a certain color),
then I'd call it ugly. Which situation do we have with pioctls?

Of course the best would be to "decouple" the communicating parties as
well, using a universally known format (so that a cfs of one architecture
could in theory talk to a venus of another architecture, over an abstract
socket).

> > ... /<indata_in_some_format>[/<more_if_needed>]

> Oh, and indata in some format is an ugly binary blob, so it has '\0' and
> '/' characters which you cannot pass as part of a path name, and
> non-ascii ones which you probably don't want to pass. So you'd need
> hexadecimal or base64 encoding.

Both hexadecimal and base64 are just straightforward examples of
"some format". Did you seriously expect me to ignore the file naming
constraints? Moreover, as we know there are no more that 2 forbidden
byte values, a different format can be more efficient but this is
not important.

The intentions were to avoid the need for ioctl() and go via plain
create()/read(). I guess this would make it. Right or not?

> > (would MAXPATHLEN size be enough for pioctl data?).
> 
> Actually MAXNAMLEN and it is in theory not enough because the pioctl api

Actually MAXPATHLEN (aka PATH_MAX) i.e. the maximum available
length of a path name - not of a component.

> allows for up to 4096 binary bytes of payload. Not sure how much cfs
> calls realistically use though.

It looks PATH_MAX would be about almost enough (slightly less space than
4096 because of escaping '\0' and '/' and the necessary additional '/'s).

Too bad, we seem to have CODA_MAXPATHLEN defined as 1024, which is
much less.

Hmm. Remarkably, in many/most places in the code MAXPATHLEN
is being referred to, not CODA_MAXPATHLEN, this does not look extremely
consistent?

I see even a comment
--------
        * ======== Release 6.0.4 =========
 ...
        * Fix some [CODA_](MAXPATHLEN|MAXNAMELEN) confusion
--------
but I do not feel that the confusion has disappeared since then :)

> currently no FUSE interface at all. I don't think anybody has even
> looked at if its threading expectations would even work with Coda's
> userspace threading.

AFAIK there is an implementation of the collaborative threads on top
of Posix threads, made by you. Do you mean above "any implementation
of the cooperative threading model used by Coda", not necessarily the
traditional userspace implementation? Or is there something which makes
the pthreads-based lwp library not applicable?

Best regards,
Rune