On Jun 22, 2005, at 8:20 PM, YAMAMOTO Takashi wrote:

> is there any os which uses the compatible semantics with this?
> why don't you follow the existing conventions like tru64 cdsl or
> dragonfly varsym?

Having fetched the necessary bits of kernel source, I've looked at  
Dragonfly varsym.  Issues:

1. I don't like the syntax they use.  Creating a magic symlink in  
Dragonfly requires you to escape the variable name on the command  
line because they use the same variable syntax as the shell.  Sure,  
it's not a huge deal, but none of the other types of magic symlinks  
that have come before varsym have ever made that mistake.

2. Dragonfly allows non-priv'd users to set per-process and per-uid  
symlink variables.  I'm not sure I like that, for the following reasons:
=> The lookup rules favor per-proc/uid variables over system  
variables.  This could cause behavior the system administrator did  
not intend.
=> It's pretty easy for each process to arbitrarily consume ~2.5MB of  
wired kernel memory just by setting up its limit of symlink variables.
=> There doesn't seem to be any protection against inserting namei- 
significant characters (e.g. ".." and "/") into the expanded  
symlink.  Again, coupled with the unfortunate lookup rules, this  
could cause behavior the system administrator did not intend.

3. Dragonfly doesn't have any built-in system-wide symlink  
variables.  So, what default magic symlink expansions are there to be  
compatible with?

4. Dragonfly doesn't have any symlink variables that automatically  
expand to other bits of system information; for instance, the only  
way to get the equivalent of e.g. @hostname or @domainname would be  
to duplicate that bit of system configuration information.  I don't  
find that to be particularly useful.


As far as Tru64 CDSLs are concerned, it appears from the  
documentation that the only variable supported by CDSL is {memb},  
which is specific to Tru64 cluster environments.  There doesn't seem  
to be much point in being compatible with their semantics.


As far as prior art for the matching rules goes, I believe our  
matching rules are compatible with AFS, although we use different  
variables than AFS does.

-- thorpej