On Thu, Jun 23, 2005 at 08:26:00AM -0700, Jason Thorpe wrote:
> 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.

This was active choosen exactly for that reason. It is something
the user is already familiar with. The same argument could be said
with make vs. shell, so it is already well-known.

> 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.

Anything else doesn't make sense when you want to allow user / process
entries. One idea was to use it e.g. for pkg-alternative style links
and you want to allow a user to override the administrator's setting
for that.

> => 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.

Well, we have already more than enough options to consume wired kernel
memory. I don't think that's a good argument.

> => 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.

Why should e.g. ".." be disallowed? I can actually think of good
reasons to allow that.

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

You can set them via /etc/rc.

> 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.

Well, I would add hooks in the necessary parts to update the varsym
entry on change if that is desired behaviour.

Joerg