[OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT

[Derrick J Brashear]

Why not issue numbers even if they never see deployed code?

On Tue, 20 Feb 2007, Matt Benjamin wrote:

> -----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-----
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>