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 [email protected]. (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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
