[OpenAFS-devel] DRAFT: New sysname standard

[Nathan Neulinger]

The code to handle @sys looks pretty trivial to me. I think that a
little effort should be put into making @ variables fully dynamic. If an
admin decided not to use it, then that's fine, but at least the
functionality would be there.

-- Nathan

Garance A Drosihn wrote:
> 
> 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
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel

-- 


------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216