Finally.... I apologize for taking 2 months to get this written. Looking at the elders mailing list archives, its clear that I spent at least 10 times as much energy debating the document as I did writing it. Oh well, no excuses.... I am well aware that the tables are incomplete (we need a comprehensive list of values, of course), and I welcome additions, but of more importance is the clarity of the specification of the sysname syntax. It feels nearly sufficient, but I feel something isn't clear. Hopefully you will all tell me what that is.Title: OpenAFS Sysname Naming Conventions
OpenAFS Sysname Naming Conventions
Index
Background
Syntax
Background
The sysname values which are hardcoded into the OpenAFS cache manager offer administrators a very powerful mechanism for managing access to platform specific data in /afs, via the @sys expansion mechanism. However, the default values are often not sufficiently descriptive of the types of binary that can run on a given platform, and at many sites, the sysname values have been customized, encoding additional information.
This document seeks to define a standard for sysname values that is descriptive enough to provide administrators with the granularity necessary to manage all possible binary types on each platform. These new style sysnames will be used for all new ports of OpenAFS, and administrators are encouraged to migrate to this convention at sites that already customize the sysname.
Syntax
The sysname will be a string, consisting of 3 required and 1 optional fields, seperated by underscores. The fields are: architecture, operating system, operating system version, and the optional ABI field.
-
Architecture
The architecture field describes the CPU, and is typically associated with a chip set, such as "sun4u" for Sun's UltraSparc. The architecture field can be interpreted independent of the other 3 fields.
-
Operating System
This field identifies the operating system. This field can be interpreted independent of the archicture, but it determines the context for the remaining two fields.
-
Operating System Version
This field identifies the numeric operating system version. For simplicity (and ease of reading), version numbers which are all single digits can have the dots unambiguously removed. For example, "2.4" would be represented as "24", or "2.4.1" could be represented as "241", but "2.41" could not be simplified to "241" since it would be ambiguous; does it represent "2.41" or "24.1"?
This field must be interpreted in the context of the operating system (hopefully obviously).
-
ABI Version (optional)
This field identifies any additional ABI information necessary to distinguish different binary types on the same operating system version. For example, the glibc version on Linux, or the 32 or 64 bit ABI for Solaris would both require this field.
The interpretation of the ABI is specific to at least the operating system, and perhaps the version as well. It is difficult to specify how to interpret this field, since its usage and the underlying differences it identifies are many and varied.
Examples
Nothing clears up confusion like real world examples.
-
ia64_linux_24_22
Intel Itanium (ia64) running Linux 2.4.X with glibc 2.2
-
alpha_osf_20
DEC Alpha running OSF 2.0
-
sun4u_sunos_58_64
Ultra Sparc (sun4u) running Solaris 8 (SunOS 5.8), with the kernel booted in 64 bit mode.
A complete list of currently defined values for each field is as follows.
Specifications
Architecture
| Vendor | Value | Description |
|---|---|---|
| Intel | ia64 | 64 bit Intel Chips (Itanium) |
| ia32 | 32 bit Intel Chips (Pentium, x86, etc) | |
| Sun | sun4c | Sparcstation 2, IPC, etc. |
| sun4m | Sparcstation 10, VMS bus machines, etc | |
| sun4u | UltraSparc | |
| MIPS | mips3 | |
| mips4 |
Operating System
NOTE: Most of these descriptions seem pedantically obvious
| Value | Description |
|---|---|
| linux | All Linux Distributions |
| sunos | SunOS or Solaris |
| aix | IBM's AIX |
| irix | SGI's IRIX |
| tru64 | DEC's Tru64 |
| nt | Microsoft Windows NT |
| os390 | IBM's OS/390 |
| hpux | HP's HP-UX |
| ultrix | DEC's Ultrix |
Operating System Version
Since the values of these tokens are simply a trivial reduction of the operating system's official version number, a comprehensive table isn't necessary. However, it is important to discuss how many sub-version components of a release need to be included in the string embedded into the sysname.
For example, Solaris 2.5.1 (SunOS 5.5.1) represented a minor release and a relatively insignificant set of changes from 2.5 (5.5). Therefore, the sysname value is simply "55", without the additional "1". Whether or not the sub-version component of the string is necessary or not depends entirely on how compatible the new release is with the previous version, in particular with respect to kernel extensions.
ABI
For simplicity, it is preferable to omit this field, if at all possible. However, the reality is that at least two platforms require the ABI specification.
-
Linux (GNU libc)
Due to the incompatibilities introduced from one glibc release to the next, in practice selerate binaries must be deployed for each distinct release of glibc. In this case, the ABI field is the flattened release number of the glibc version on that platform. That is, it follows the same "no-dots" rules as the operating system version.
-
Solaris (32 vs 64 bit)
On newer Sun hardware, the same hardware and OS version can be booted into either 32 or 64 bit modes. 64 bit binaries can only be run when a host is booted into 64 bit mode. The ABI field in this case is either "32" or "64".
As other ABI requirements arise, they will be defined as appropriate.
W. Phillip Moore Last modified: Tue Apr 24 16:49:08 EDT 2001
