[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> </DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D599542113-03012008>The proposal was to perform expansion on =
any path=20
entry that began with <A href=3D"mailto:'@'">'@'</A> and resolve =
according to=20
a cell-wide table and an optional override at the AFS client. =
<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. </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 be =
defined at the=20
client. 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> </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 <<A=20
href=3D"http://linux.die.net/include/sys/utsname.h">sys/utsname.h</A>>=
) 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>. 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> </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) . As long as this minimal set could not =
be=20
overridden (i.e., the behavior is predictable), 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> </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> </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> </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 <<A=20
href=3D"mailto:rra@stanford.edu">rra@stanford.edu</A>> 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" <<A=20
href=3D"mailto:avinesh@gmail.com">avinesh@gmail.com</A>> =
writes:<BR><BR>>=20
Seem the right reason to do this in past !<BR>> 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>) =
=20
<<A href=3D"http://www.eyrie.org/%7Eeagle/"=20
=
target=3D_blank>http://www.eyrie.org/~eagle/</A>><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--