[OpenAFS-devel] DRAFT: New sysname standard

[Phil.Moore@morganstanley.com]

>>>>> "Chas" == Chas Williams <chas@cmf.nrl.navy.mil> writes:
>>>>> "Nathan" == Nathan Neulinger <nneul@umr.edu> writes:

Chas> just a comment about the linux sysnames.  it seems redundant to
Chas> specify the kernel version in there since that usually its the
Chas> important piece.  if i had to do it over again, i would have
Chas> renamed i386_linux22 to just i386_linux using the '#if
Chas> KERNEL_VERSION >' to handle any differences.  this wouldnt have
Chas> taken into account glibc differences though.

Chas> if you have ia64_linux_24_22 and ia64_linux_22_22 you are going
Chas> to have two sets of afs binaries that are essentially the same.
Chas> perhaps just having i386_linux_22 (were 22 is the abi) would be
Chas> 'better'?  just distribute/build the appropriate different
Chas> kernel modules.

You are missing a critical point here.

Nathan made a similar argument on the openafs-elders list, and I'll
replicate that component of the discussion here:

Nathan> Granted, this is semi-redundant, but in the case of things
Nathan> like Solaris 2.5.1, it would be good to have something that
Nathan> says:

Nathan> sun4u_sunos_55 = Solaris 2.5 and 2.5.1 on UltraSparc

Nathan> I'd also like to suggest that some sort of wildcard be
Nathan> specified in the standard. For example, builds that work on
Nathan> sun4m and sun4u.

Well, I have to disagree, because even though the AFS kernel module
may work on more than one platforms, I still want each of them to have
a distinct @sys value, since I may need to have a distinct platform
specific AFS volume/directories.

For example, as of 3.4 (I beleive -- my memory may be incorrect), the
same loadable AFS kernel module would work for both sun4c and sun4m.
However, I still needed to distinguish between these two platform
types for applications.  Therefore, each platform needs a unique @sys.

In this case, obviously there can be only one sysname value hardcoded
into the loadable module, but so what?  "fs sysname" can fix that.  I
would like to see a mechanism for specifying this in a file, too.  For
example, /usr/vice/etc/sysname, or a similarly named file.

The point is: the sysname values needs to describe the machine on
which the cache manage is currently running with sufficient
granularity, and not be a more generic specification that describes
the set of platforms on which the kernel module can be loaded.