On Tue, Mar 10, 2009 at 3:02 AM, Felix Frank <[email protected]> wrote: > 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)?
I'd assume some way of representing per-file ACLs will appear, but i'd have to think harder what you'd want to use to represent it. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
