[OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT

[Matt Benjamin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeff,

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.

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.

It seems reasonable to include us in discussions of the evolution of
these interfaces, as we have submitted code lo these many months ago for
your (and Derrick's) review, and updated frequently thereafter.  We have
email, and are subscribers to openafs-devel@openafs.org.

As for pioctls, we'll happily send a request to
registrar@grand.central.org 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?

Matt

Jeffrey Hutzelman wrote:
> 
> 
> On Sunday, February 18, 2007 01:23:42 AM -0500 Marcus Watts
> <mdw@umich.edu> wrote:
> 
>>> Date: Fri, 16 Feb 2007 12:50:38 -0500
>>> From: Jeffrey Hutzelman <jhutz@cmu.edu>
>>> To: Marcus Watts <mdw@umich.edu>, openafs-devel@openafs.org
>>> cc: Jeffrey Hutzelman <jhutz@cmu.edu>
>>>
>>> We bashed out a lot of the details of what the new interfaces will look
>>> like and what the fallback and transition mechanisms need to be at the
>>> rxgk  hackathon last month.  Details, including the specifications for
>>> the new  VIOCGETTOK2 and VIOCSETTOK2 pioctls, can be found at
>>>
>>> <http://www.afsig.se/afsig/space/rxgk-client-integration>
>>>
>>> -- Jeff
>>>
>>
>> Interesting.  rxk5 already has a VIOC_GETTOKNEW VIOC_SETTOKNEW using
>> _CVICEIOCTL(7) and (8).  Is this a proposal to build on top of that
>> interface?
> 
> 
> This is the interface we propose to actually implement in the cache
> manager, instead of the one that was in your patches.  The interface you
> had was not rich enough to handle multiple tokens per cell, which is
> necessary for the transition and fallback behavior we defined.  The
> impression I got from Jeff and Derrick was that you didn't have rxk5
> deployed anywhere where this change would be a problem,
> 
> Incidentally, your patch also uses three 'C' pioctl numbers (6,7,8)
> without them actually having been assigned to you; the recent patch from
> Matt Benjamin makes the same mistake.  Numbers in this space must be
> obtained by sending a request to registrar@grand.central.org; otherwise,
> you risk causing a collision, as the GetCapabilities pioctl included in
> the rxgk patch does -- _CVICEIOCTL(6) is already assigned for
> VIOC_CREATE_MT_PT.
> 
> -- Jeff
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel




- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF23GCJiSUUSaRdSURCOEcAJsGdYfZg6hbDPkpmM703GXhnhSzDgCfQ2tq
kLqmgVbzyBRcfgVSuxHq2yI=
=88/T
-----END PGP SIGNATURE-----