[OpenAFS-devel] [grand.central.org #124130] Re-opening the discussion (fwd)

[Felix Frank]

On Mon, 9 Mar 2009, Jeffrey Altman wrote:

> We need a new AFSFetchStatus64 (and everything else that has a time) so
> that we can support 64-bit time values.  The question is what else do we
> need to add?  We can always add new RPC values when we add new
> functionality.  Doing so provides a built in negotiation mechanism:
>
> * clients only ask for what they support
> * servers only send what they support
>
> The question is simply what are all of the things we know today that
> need to go into the new RPCs and writing a proposal document to be
> sent to afs3-stds so that the protocol discussion can take place.
> The protocol is not limited to OpenAFS.

I like the way this is going. I'm not quite sure whether you're saying we
need to draft an extension to the whole protocol (I think you're not).
In any case, I propose we come up with the AFSFetchStatus64 + RPCs sooner
rather than later, speaking in the interest of OSD integration.
We might even economize on design thoroughness by including sufficient spare
space in the struct, no?

I don't know whether this thread is an appropriate place to gather needed
fields. Regardless, this is what I can see so far:

struct AFSFetchStatus {
     afs_uint32 InterfaceVersion;
     afs_uint32 FileType;
     afs_uint32 LinkCount;
     afs_uint64 Length;
     afs_uint64 DataVersion;
     afs_uint32 Author;
     afs_uint32 Owner;
     afs_uint32 CallerAccess;
     afs_uint32 AnonymousAccess;
     afs_uint32 UnixModeBits;
     afs_uint32 ParentVnode;
     afs_uint32 ParentUnique;
     afs_uint32 ResidencyMask;   /* is this needed? cscope tells me of 3 places
                                    changing this, but none reading it */
     afs_uint64 ClientModTime;
     afs_uint64 ServerModTime;
     afs_uint64 LastVolChangeTime; /* I don't know what this is truly called */
     afs_uint32 Group;
     afs_uint32 Protocol;
     afs_uint32 lockCount;
     afs_uint32 errorCode;
     afs_uint32 spare[39];   /* -> 64 DWORDs */
};

Should memory alignment in 64-bit environments be considered (i.e., should
uint64s appear at "even" positions in the struct)?

>> Doing this, however, we must make sure not to get an overlap in the RPC
>> numbers! When I modified the code for MR-AFS and later for OpenAFS+OSD I
>> let a gap between the last RPC-number used by OpenAFS and the first one
>> I used.  This gap has shrunk to to eight (65543-65550) in the meantime.
>
> This is why we have a registration system.  Developers must not select
> their own RPC values.  The values must be issued by the registrars.
> OpenAFS gatekeepers cannot issue RPC assignments.  Send requests for
> RPCs to registrar@grand.central.org.  (and if you don't get a timely
> response, we know where they live.)

I should then try and register all of Hartmut's new RPCs with them.

Regards
Felix