"Matt W. Benjamin" <[email protected]> writes: > As a starting point for discussion, I wish to make the following > proposal: > > 1. as apparent patch maintainer for fetchvstatus, the only change I am > aware of (so far) which conflicts with the rxosd change, in claiming > the AFSFetchStatus SyncCounter, I propose that SyncCounter be > allocated to rxosd, renaming to Protocol > > 2. I propose that fetchvstatus be added to the list of features to be > accommodated in the upcoming round of extended AFSFetchStatus > discussions > > 3. I would request that any other claimants of SyncCounter or of the > spare0 and spare3 members in volintInfo (claimed as osdPolicy and > filequota in rxosd) disclose their use here, or otherwise state here > how they would be harmed by allocating these members to rxosd.
I think you may have missed part of the point of the discussion at the workshop here. The problem is that, because these fields are not and were not standardized at all and existing software would ignore them, people may have used them. Those people may not be here. If we start using them for some other purpose, it could break their software, and makes the upgrade path complicated. This is somewhat akin to having an exported but not documented function in a library API. Just because it's not documented doesn't mean that one can safely remove it. Protocol on the wire is even worse, since it's hard to update all the pieces at the same time. The safe thing to do in that situation is to do a more complete protocol revision rather than reusing a field that other people may already be using. That way, the fields can be defined for a clear purpose from the start, everyone can move to the new protocol, and nothing breaks about old legacy code. The importance of doing this as opposed to just saying that anyone else who used the existing field loses depends heavily on how important backward compatibility is and whether one can do an effective survey of users to figure out what would break by repurposing fields. I think AFS is in a situation where we can neither do an effective survey nor decide backward compatibility is unimportant. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
