[OpenAFS] why linux sysnames are different

Stumpf, Jon Jon.Stumpf@AIG.com
Thu, 3 Jan 2008 09:04:27 -0500


This is a multi-part message in MIME format.

------_=_NextPart_001_01C84E11.99AC0E3E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

While at Transarc many years ago, I proposed an extension to path =
lookups to address deficiencies in @sysname similar to what is being =
discussed here.
=20
The proposal was to perform expansion on any path entry that began with =
'@' and resolve according to a cell-wide table and an optional override =
at the AFS client.  The cell-wide table would define the list of =
variables that would be allowed to be set within the cell.  The =
cell-wide table could specify entries that could not be overridden and =
also entries required to be defined at the client.  If a variable could =
not be expanded, an ENOENT would be returned on open(2), creat(2), or =
rename(2).
=20
The initial variable list was to include all entries in the utsname =
structure (defined in <sys/utsname.h =
<http://linux.die.net/include/sys/utsname.h> >) as returned by uname(2) =
<http://linux.die.net/man/2/uname> .  Extended uses could include things =
beyond architecture such as department, location, etc. as determined by =
the administrators of the cell as requirements dictated.
=20
Over time, a subset of possible variables (e.g., sysname, the utsname =
entries) would be provided by the AFS codebase (the minimal set) .  As =
long as this minimal set could not be overridden (i.e., the behavior is =
predictable), it would be applicable across all cells.
=20
- jss
=20
Ref:
http://linux.die.net/include/sys/utsname.h
http://linux.die.net/man/2/uname=20

=20
________________________________

From: openafs-info-admin@openafs.org =
[mailto:openafs-info-admin@openafs.org] On Behalf Of Avinesh Kumar
Sent: Wednesday, January 02, 2008 6:41 PM
To: openafs-info@openafs.org
Subject: Re: [OpenAFS] why linux sysnames are different



We can keep the old sysnames as is, and invent a new convention
based on kernel version or glibc version for newer systems. This
way we would be backward compatible and probably solve the problem
for newer systems as well.=20



On Jan 2, 2008 5:43 PM, Russ Allbery <rra@stanford.edu> wrote:


	"Avinesh Kumar" <avinesh@gmail.com> writes:
=09
	> Seem the right reason to do this in past !
	> But the problem is still there.
=09
=09
	And probably always will be, since changing sysnames is a nasty
	backward-incompatible change and people have already build =
infrastructure
	on local interpretations or workarounds for the existing sysnames.
=09
	I suppose we could start setting a sysname list based on both the =
kernel
	version and the glibc version by default, but I shudder to think of the
	Autoconf glue.
=09
	--
	Russ Allbery ( rra@stanford.edu <mailto:rra@stanford.edu> )             =
<http://www.eyrie.org/~eagle/ <http://www.eyrie.org/%7Eeagle/> >
	_______________________________________________
	OpenAFS-info mailing list
	OpenAFS-info@openafs.org
	https://lists.openafs.org/mailman/listinfo/openafs-info
=09



------_=_NextPart_001_01C84E11.99AC0E3E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D599542113-03012008>While at Transarc many years ago, I proposed =
an=20
extension to path lookups to address deficiencies in @sysname similar to =
what is=20
being discussed here.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D599542113-03012008></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D599542113-03012008>The proposal was&nbsp;to perform expansion on =
any path=20
entry that began with <A href=3D"mailto:'@'">'@'</A>&nbsp;and resolve =
according to=20
a cell-wide table and an optional override at the AFS client.&nbsp; =
<FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D599542113-03012008>The cell-wide=20
table would define the list of variables that would be allowed to be set =
within=20
the cell.&nbsp; </SPAN></FONT></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><SPAN class=3D599542113-03012008>The cell-wide table could =
specify entries=20
that could not be overridden and also entries required to&nbsp;be =
defined at the=20
client.&nbsp; If a variable could not be expanded, an ENOENT would be =
returned=20
on open(2), creat(2), or rename(2).</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D599542113-03012008></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D599542113-03012008></SPAN></FONT><FONT face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>T<SPAN class=3D599542113-03012008>he =
initial variable=20
list was to include all entries in the <STRONG>utsname</STRONG> =
structure=20
(defined in &lt;<A=20
href=3D"http://linux.die.net/include/sys/utsname.h">sys/utsname.h</A>&gt;=
) as=20
returned by <A=20
href=3D"http://linux.die.net/man/2/uname">uname(2)</A></SPAN></FONT></FON=
T></FONT><FONT=20
face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D599542113-03012008>.&nbsp; Extended uses could include things =
beyond=20
architecture such as department, location, etc. as determined by the=20
administrators of the cell as requirements=20
dictated.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D599542113-03012008></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D599542113-03012008>Over time, a subset of possible variables =
(e.g.,=20
sysname, the utsname entries) would be provided by the AFS codebase (the =
minimal=20
set)&nbsp;.&nbsp;&nbsp;As&nbsp;long as this minimal set&nbsp;could not =
be=20
overridden (i.e., the behavior is predictable),&nbsp;it would be =
applicable=20
across all cells.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D599542113-03012008></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2>- =
jss</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D599542113-03012008></SPAN><FONT face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>Ref:</FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><A=20
href=3D"http://linux.die.net/include/sys/utsname.h">http://linux.die.net/=
include/sys/utsname.h</A></FONT></FONT></FONT></DIV><U><FONT=20
face=3DArial color=3D#0000ff size=3D2><A=20
href=3D"http://linux.die.net/man/2/uname">http://linux.die.net/man/2/unam=
e</A></FONT></U>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D599542113-03012008></SPAN></FONT></FONT></FONT><BR>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> openafs-info-admin@openafs.org =

[mailto:openafs-info-admin@openafs.org] <B>On Behalf Of </B>Avinesh=20
Kumar<BR><B>Sent:</B> Wednesday, January 02, 2008 6:41 PM<BR><B>To:</B>=20
openafs-info@openafs.org<BR><B>Subject:</B> Re: [OpenAFS] why linux =
sysnames are=20
different<BR></FONT><BR></DIV>
<DIV></DIV><BR>We can keep the old sysnames as is, and invent a new=20
convention<BR>based on kernel version or glibc version for newer =
systems.=20
This<BR>way we would be backward compatible and probably solve the=20
problem<BR>for newer systems as well. <BR><BR><BR>
<DIV class=3Dgmail_quote>On Jan 2, 2008 5:43 PM, Russ Allbery &lt;<A=20
href=3D"mailto:rra@stanford.edu">rra@stanford.edu</A>&gt; wrote:<BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
  <DIV class=3DIh2E3d>"Avinesh Kumar" &lt;<A=20
  href=3D"mailto:avinesh@gmail.com">avinesh@gmail.com</A>&gt; =
writes:<BR><BR>&gt;=20
  Seem the right reason to do this in past !<BR>&gt; But the problem is =
still=20
  there.<BR><BR></DIV>And probably always will be, since changing =
sysnames is a=20
  nasty<BR>backward-incompatible change and people have already build=20
  infrastructure<BR>on local interpretations or workarounds for the =
existing=20
  sysnames.<BR><BR>I suppose we could start setting a sysname list based =
on both=20
  the kernel<BR>version and the glibc version by default, but I shudder =
to think=20
  of the<BR>Autoconf glue.<BR><FONT color=3D#888888><BR>--<BR>Russ =
Allbery (<A=20
  href=3D"mailto:rra@stanford.edu"> rra@stanford.edu</A>) &nbsp; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &lt;<A href=3D"http://www.eyrie.org/%7Eeagle/"=20
  =
target=3D_blank>http://www.eyrie.org/~eagle/</A>&gt;<BR>_________________=
______________________________<BR>OpenAFS-info=20
  mailing list<BR><A=20
  =
href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</A><BR>=
<A=20
  href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info"=20
  =
target=3D_blank>https://lists.openafs.org/mailman/listinfo/openafs-info</=
A><BR></FONT></BLOCKQUOTE></DIV><BR></BODY></HTML>

------_=_NextPart_001_01C84E11.99AC0E3E--