[AFS3-std] RxOSD claim on 2 structure members

[Russ Allbery]

"Matt W. Benjamin" <matt@linuxbox.com> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>