> Changing it is certainly possible, but doing so on the basis of that > documentation is weak.
Study of ancient source shows that the documentation has been out of sync with reality (if it has ever been in sync) since at least 3.3. I suggest we define the following as the current behavior: ---------------------------------------------------------------------- The first afs_int32 value in the outbuffer contains a flag which makes the call a get or a set. 0 for get and 1 for set. It it is a set, the following bytes have to contain a null terminated string with the sysname. Both the set and get variation of the call fills in the inbuffer according to the following: The first afs_int32 value in the inbuffer is nonzero if there is a sysname in the buffer, 0 otherwise. The sysname is contained in a null terminated string directly after the afs_int32 value. ---------------------------------------------------------------------- As I can see, this is the behaviour of transarc 3.3, 3.4, 3.5, 3.6 and all Arla versions. For the set case this is according to the documentation, too. Then we can discuss if the pioctl should be extended in the following way: ---------------------------------------------------------------------- The first afs_int32 value in the outbuffer contains 0 for a get call and the number of sysname strings for a set call. It it is a set, the following bytes have to contain the same number of null terminated strings with the sysnames which will be set. Both the set and get variation of the call fills in the inbuffer according to the following: The first afs_int32 value in the inbuffer is the number of sysnames if there is a sysname list in the buffer, 0 otherwise. The sysname list contains the same number of null terminated strings directly after the afs_int32 value. ---------------------------------------------------------------------- or if we should keep the existing call interface and have a new call for sysname lists instead. Comments on my wording of the definitions and what to do and if I read the source correctly are of course welcome. Harald. _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
