A note on choice of forum...
The openafs-devel mailing list is an appropriate place for discussions
related to the design and development of OpenAFS, and much of this falls
into that category. However, discussion of the design of the protocols
themselves, including the 'C' pioctl space, belongs on the separate
[email protected] list. Since this thread contains a bit of
each, I have copied both lists.
On Tuesday, February 20, 2007 05:09:06 PM -0500 Matt Benjamin
<[EMAIL PROTECTED]> wrote:
Actually, the token interface we authored has some properties we would
not like to see discarded in a new interface. In particular, we value
the XDR token description, which allows us to define an afs_token as an
abstract type (with rxkad and rxk5 subtypes), and generated
serialization/deserialization code instead of tedious and ugly hand
marshalling on ioctl buffers.
OK; this is worth discussing further. It's worth noting that the remote
syscall protocol needs to know exactly what the arguments are for most of
the existing pioctl's, so it can do byte-order translation. Comments in
that code suggest that at some point (possibly before we got the code),
someone adopted a rule that future pioctls should take arguments expressed
in network byte order (and word size), to avoid needed to add additional
knowledge of this type to rmtsys. Using XDR would be one way to achieve
this.
Reviewing your document at afsig.se, I would draw attention to the cm
capabilities interface (also in our rxk5 patch), which as you suggested
to us at AFSBPW 2005 (unforgettable hallway discussion), allows to avoid
coding many repetitive get/(and ultimately set) ioctl calls such as
VIOCGETSUPPORTEDTOKENS and my own lock hack.
I don't recall the conversation specifically, but there certainly is an
established consensus that we should be adding get-capabilities ops to each
interface. Such an interface would return a bitmask of supported
capabilities, similar to the ones we already have in some of the RPC
interfaces. Forgive me for not going back and looking at your patch to see
if this is what you ended up defining.
Given that the number of supported token types is small, I don't see a
problem with allocating a capability bit for each one; this is probably a
better approach than using a separate pioctl.
Capabilities really don't address the lock thing, though. The capabilities
interface is intended to advertise what an interface provider is willing
and/or able to support; they are read-only by nature. They're also
something that should behave consistently across implementations. By
contrast, the locking thing is really a configuration option for the
OpenAFS cache manager; it needs both read and write, and is implementation
specific.
So, I think we're talking about three pioctl's here:
- get capabilities
- get OpenAFS CM feature bits
- set OpenAFS CM feature bits
The first belongs in the 'C' space, and there needs to be a registry for
the capabilitiy bits themselves. We're already doing this for some of the
other interfaces, though the web pages don't yet exist for all of the
registries.
I think the other two belong in 'O', since they really are specific to
OpenAFS.
I also think that neither of these interfaces covers the question of
supported enctypes. An aklog or equivalent program obtaining either rxk5
or rxgk tokens needs to know what enctypes are supported by the cache
manager, in order to avoid getting a useless ticket. My document on rxgk
client integration indicates the need for such an interface but doesn't
define one; I don't recall seeing one in your patch, either. You might
argue that supported enctypes are capabilities, but I'd rather not treat
them that way. There is already an IANA registry of RFC3961/Kerberos
enctypes, and I'd rather not have a requirement to designate a capability
bit for every enctype before it can be used.
As for pioctls, we'll happily send a request to
[EMAIL PROTECTED] for the ones we actually require. I would
ask, however, whether you really plan to issue an official pioctl, in
any range, for code that is unlikely to see wide or long-term use? Is
it possible that there should be an X ('experimental') ioctl range for
this sort of work?
I allocated numbers for VIOCGETTOK2 and VIOCSETTOK2, but the details of
these interfaces are still open for discussion. I don't believe anyone has
yet implemented the interfaces described on the afsig.se page, but if
anyone has, they certainly know that they are subject to change.
I'll be happy to allocate a number for a get-capabilities bit, if you want
to send a request in. Feel free to CC me to get it quicker attention, as I
don't wade through the spam there very often. But I always ask that you
actually send the request in to the registar address, because I use that
queue as part of my recordkeeping.
As for experimental use, the 'V' 240-247 codes are available for site
specific use in both the ioctl and pioctl spaces; these should be usable
for experimentation. There is also an implementation-specific range at
'V'248-255, which may be appropriate for some experimentation (but be
careful - OpenAFS doesn't use these codes, but other implementations might).
The various lists of assigned codes can be found at
<http://grand.central.org/numbers/>. Be aware that they sometimes get
stale, so don't assume a number is available just because it's not listed.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
