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 [EMAIL PROTECTED]
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?
Matt
Jeffrey Hutzelman wrote:
On Sunday, February 18, 2007 01:23:42 AM -0500 Marcus Watts
<[EMAIL PROTECTED]> wrote:
Date: Fri, 16 Feb 2007 12:50:38 -0500
From: Jeffrey Hutzelman <[EMAIL PROTECTED]>
To: Marcus Watts <[EMAIL PROTECTED]>, [email protected]
cc: Jeffrey Hutzelman <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]; 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
[email protected]
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
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
