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.
 
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).
 
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.
 
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.
 
- jss
 
Ref:
http://linux.die.net/include/sys/utsname.h
http://linux.die.net/man/2/uname 

 
________________________________

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Avinesh Kumar
Sent: Wednesday, January 02, 2008 6:41 PM
To: [email protected]
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. 



On Jan 2, 2008 5:43 PM, Russ Allbery <[EMAIL PROTECTED]> wrote:


        "Avinesh Kumar" <[EMAIL PROTECTED]> writes:
        
        > Seem the right reason to do this in past !
        > But the problem is still there.
        
        
        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.
        
        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.
        
        --
        Russ Allbery ( [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> )           
  <http://www.eyrie.org/~eagle/ <http://www.eyrie.org/%7Eeagle/> >
        _______________________________________________
        OpenAFS-info mailing list
        [email protected]
        https://lists.openafs.org/mailman/listinfo/openafs-info
        


Reply via email to