[OpenAFS-devel] DRAFT: New sysname standard
Phil.Moore@morganstanley.com
Phil.Moore@morganstanley.com
Tue, 24 Apr 2001 16:54:29 -0400 (EDT)
--iwr93Kb3Vn
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit
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.
--iwr93Kb3Vn
Content-Type: text/html
Content-Disposition: inline;
filename="sysnames.html"
Content-Transfer-Encoding: 7bit
<html>
<head>
<title>OpenAFS Sysname Naming Conventions</title>
</head>
<body>
<center>
<h1>OpenAFS Sysname Naming Conventions</h1>
</center>
<h1>Index</h1>
<h2><a href="#1">Background</a></h2>
<h2><a href="#2">Syntax</a></h2>
<hr>
<h1><a name="1">Background</a></h1>
<p>
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.
</p>
<p>
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.
</p>
<h1><a name="2">Syntax</a></h1>
<p>
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.
</p>
<ul>
<li>
<p>Architecture</p>
<p>
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.
</p>
</li>
<li>
<p>Operating System</p>
<p>
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.
</p>
</li>
<li>
<p>Operating System Version</p>
<p>
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"?
</p>
<p>
This field must be interpreted in the context of the
operating system (hopefully obviously).
</p>
</li>
<li>
<p>ABI Version (optional)</p>
<p>
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.
</p>
<p>
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.
</p>
</li>
</ul>
<h1>Examples</h1>
<p>
Nothing clears up confusion like real world examples.
</p>
<ul>
<li>
<p>ia64_linux_24_22</p>
<p>
Intel Itanium (ia64) running Linux 2.4.X with glibc 2.2
</p>
</li>
<li>
<p>alpha_osf_20</p>
<p>
DEC Alpha running OSF 2.0
</p>
</li>
<li>
<p>sun4u_sunos_58_64</p>
<p>
Ultra Sparc (sun4u) running Solaris 8 (SunOS 5.8), with the
kernel booted in 64 bit mode.
</p>
</li>
</ul>
<p>
A complete list of currently defined values for each field is as
follows.
</p>
<h1>Specifications</h1>
<h2>Architecture</h2>
<table border="2" cellspacing="2" cellpadding="2">
<tr>
<th>Vendor</th>
<th>Value</th>
<th>Description</th>
</tr>
<tr>
<td rowspan="2">Intel</td>
<td>ia64</td>
<td>64 bit Intel Chips (Itanium)</td>
</tr>
<tr>
<td>ia32</td>
<td>32 bit Intel Chips (Pentium, x86, etc)</td>
</tr>
<tr>
<td rowspan="3">Sun</td>
<td>sun4c</td>
<td>Sparcstation 2, IPC, etc.</td>
</tr>
<tr>
<td>sun4m</td>
<td>Sparcstation 10, VMS bus machines, etc</td>
</tr>
<tr>
<td>sun4u</td>
<td>UltraSparc</td>
</tr>
<tr>
<td rowspan="2">MIPS</td>
<td>mips3</td>
<td> </td>
</tr>
<tr>
<td>mips4</td>
<td> </td>
</tr>
</table>
<h2>Operating System</h2>
<p>NOTE: Most of these descriptions seem pedantically obvious</p>
<table border="2" cellspacing="2" cellpadding="2">
<tr>
<th>Value</th>
<th>Description</th>
</tr>
<tr>
<td>linux</td>
<td>All Linux Distributions</td>
</tr>
<tr>
<td>sunos</td>
<td>SunOS or Solaris</td>
</tr>
<tr>
<td>aix</td>
<td>IBM's AIX</td>
</tr>
<tr>
<td>irix</td>
<td>SGI's IRIX</td>
</tr>
<tr>
<td>tru64</td>
<td>DEC's Tru64</td>
</tr>
<tr>
<td>nt</td>
<td>Microsoft Windows NT</td>
</tr>
<tr>
<td>os390</td>
<td>IBM's OS/390</td>
</tr>
<tr>
<td>hpux</td>
<td>HP's HP-UX</td>
</tr>
<tr>
<td>ultrix</td>
<td>DEC's Ultrix</td>
</tr>
</table>
<h2>Operating System Version</h2>
<p>
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.
</p>
<p>
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.
</p>
<h2>ABI</h2>
<p>
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.
</p>
<ul>
<li>
<p>Linux (GNU libc)</p>
<p>
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.
</p>
</li>
<li>
<p>Solaris (32 vs 64 bit)</p>
<p>
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".
</p>
</li>
</ul>
<p>
As other ABI requirements arise, they will be defined as
appropriate.
</p>
<hr>
<address><a href="mailto:Phil.Moore@morganstanley.com">W. Phillip Moore</a></address>
<!-- Created: Thu Mar 22 17:07:14 EST 2001 -->
<!-- hhmts start -->
Last modified: Tue Apr 24 16:49:08 EDT 2001
<!-- hhmts end -->
</body>
</html>
--iwr93Kb3Vn--