brezak> But way cool - Think of building multiple architectures on one machine
brezak> with the "obj" links in the form of
brezak> "ln -s /usr/obj.@arch/bin/ls /usr/src/bin/ld/obj" .

What's wrong with multiple ./obj.$ARCH links in the source tree?  Works fine
for me.  eg:
	/usr/src/bin/cat/obj.i386 -> /usr/obj.i386/bin/cat
	/usr/src/bin/cat/obj.icm3216 -> /usr/obj.icm3216/bin/cat

The .mk rules can handle the choice of obj directories in the same way that
they choose the appropriate cross-compilers/etc.

There are ways around diluting the fs namespace with special macros, but
it's a matter of weighing up the pros/cons of simplifying the user's
world or the kernel's world...

Once you start adding @{KEYWORD} to the namei stuff, you open a can of worms.
From one point of view, expanding environment variables in there is a neater
solution, as variables such as $ARCH, $HOST, etc can be defined along with
anything else the user dreams up.  But security risks are raised by this
also.

Where do you do the expansion?  Only in symbolic links?  That way the changes
fit "neatly" into the fs-independent namei code and it suddenly works across
all fs types.

I recall posting some thoughts on this _quite_ some time ago (I've used
env-var expansions in symbolic links on DomainOS and Sony's 4.3BSD port,
and combining the syntax of the two would be neat).  I can expand on this
again if anyone's interested.

- David B.

------------------------------------------------------------------------------