Path: utzoo!attcan!uunet!husc6!mailrus!ames!oliveb!pyramid!prls!mips!dce
From: dce@mips.COM (David Elliott)
Newsgroups: comp.unix.wizards
Subject: Re: Magic symlink syntax
Keywords: nami hack, namei hack
Message-ID: <2435@quacky.mips.COM>
Date: 18 Jun 88 14:42:15 GMT
References: <2371@quacky.mips.COM> <126@vertical.oz>
Reply-To: dce@quacky.UUCP (David Elliott)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 37

In article <126@vertical.oz> greg@vertical.oz (Greg Bond) writes:
>In article <2371@quacky.mips.COM> dce@mips.COM (David Elliott) writes:
>>This is the modification that allows one to put a variable inside of
>>a symbolic link target so that people can choose default execution
>>"universes" or "modes" or "system types".
>
>What do you mean by a variable?  How can such variables be set up so
>that the kernel context can access them?  Not shell variables,
>obviously (as the process doing the system call is not in general a
>shell), but even "environment" variables can be changed by the process
>and I can't see how namei would know where to look for them.

It really doesn't matter what kind of variable.  Even the Pyramid
"universe" is a kind of variable; it's just restricted to two values.

My original description is quite restrictive, as it states that it
allows people to choose default execution "universes".

With this restriction, it's quite easy to set it up so that the
value of the variable gets passed to the kernel.  The system call
wrapper could simply decode the current value of an environment
variable and pass it to the kernel.

A variation of this is to have the system call interface send the
environment pointer to the kernel.  You can send pointers to other
types of objects, why not the environment?

Another option is to say that the "variable" is set by a system
call, as the umask or the nice value is.

Obviously, the first two methods can cost extra time, so care must
be taken to understand how to do it.  The thing to remember is that
we (meaning the company developing the system) owns the system call
interface, so we can modify it as needed.

-- 
David Elliott		dce@mips.com  or  {ames,prls,pyramid,decwrl}!mips!dce