[OpenAFS-devel] DRAFT: New sysname standard

[Garance A Drosihn]

At 10:30 PM -0400 4/24/01, aeneous@speakeasy.org wrote:
>Actually, it looks good.  I think the reason that it feels
>awkward is that it crams all this stuff into a single variable.
>However, AFS only has the one @  variable, and without changing
>that, I think you're stuck.  So, given the  limitation of a
>single variable I think it's sufficient.

We've run AFS here at RPI for something like ten years, and my
opinion is that it is just impossible to stuff "all the right
things" into that single variable.  I think the openafs project
should seriously consider having more than one @-variable.

The @sys variable from the standard AFS implementation is
merely supposed to identify which version of AFS binaries
you need.  Everyone immediately sees this is useful for OTHER
purposes, and then we get into trouble when Transarc DOES
change the @sys name when we don't want it changed (for those
other purposes), and when Transarc does NOT change it when we
DO want it changed (for those other purposes).

I would suggest that we stop frustrating ourselves by trying
to have one variable serve multiple purposes.  Even though
those purposes are CONCEPTUALLY similar, they are not going
to be served by a single variable which can only have a single
value.  If this means that openafs expands @arch, while standard
afs leaves that as a literal '@arch', then so be it.  We have
never come up with a satisfactory naming scheme in the past
ten years of having this single variable, and I can not imagine
we ever will unless we have more variables to work with.  We
should pick values for @sys which are as useful as the ones
transarc picks, and then solve other user-land problems via
other @-variables.

A very short list of variables is obviously preferable, but
"one" is a bit too short.  Just my opinion...

At 5:05 PM -0400 4/25/01, Ted McCabe wrote:
>At 4:49 PM -0400 4/25/01, Derek Atkins wrote:
>>First, @sys is purely a client issue, so there really isn't
>>a compatibility issue in the first place.  Second, this is
>>only a concern for _new ports_ for which transarc doesn't
>>even have support (otherwise it would already be in OpenAFS).
>
>The second statement assumes that Transarc makes no new ports.
>Since we must currently assume that Transarc will make more
>ports in the future, we must initially have a standard that
>is compatible with Transarc's clients.

As a separate issue, if we MUST ensure that openafs values
for @sys do not conflict with standard AFS names (and that
does seem like a good idea), then we should explicitly
address that in the naming scheme used for openafs.

I suggest that all @sys values for openafs should either
start with 'o_' or end with '_o'.  That way, there can only
be a conflict if someone at transarc/ibm really tries to
make a conflict.  I do not expect anyone there to be that
obnoxious, so I think this would be a good solution.

-- 
Garance Alistair Drosehn            =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu