Magic symlinks redux

Luigi Rizzo rizzo at iet.unipi.it
Fri Aug 22 11:27:06 UTC 2008


On Fri, Aug 22, 2008 at 12:24:41PM +0200, Ivan Voras wrote:
> Andrey V. Elsukov wrote:
...
> 
> >This was so long ago.. As i remember this patch is a quick port of
> >NetBSD's implementation and uses the same code.
> >
> >Also there was another implementation ported from DragonFlyBSD.
...
> This patch is huge. As far as I can tell DragonflyBSD has a whole 
> framework dedicated to varsyms, spread across a fair part of the kernel 
> and with at least one special userland utility. It allows the operator 
> to define his own variables that can be used in the substitutions, and I 
> don't see that it predefines "special" variables like "uid" and 
> "hostname". It's not necessarily a bad solution but I consider it overkill.
> 
> Anyway, the syntax of DFBSD's varsyms is similar but sufficiently 
> different from NetBSD's magicsyms implementation that both can coexist. 
> DFBSD uses  ${var} and NetBSD uses @var or @{var} so there's no 
> ambiguity between them.
> 
> Unless a kernel developer is interested in working the DFBSD's 
> implementation in, I'll push the NetBSD's variant.

i also believe the simple solution is much more interesting.

However i believe a crucial issue (in terms of implementation) is
to define exactly the behaviour in error or corner cases, namely:

+ what to do if we try to expand @{nonexistentkeyword} ?
	i suppose leave the string as-is is the right thing.

+ what to do if, as a result of the expansion, we exceed MAXPATHLEN ?
	here it is really unclear whether returning the original
	is ok, or there is a way to report some kind of error.

Also what is the exact syntax for @var ? From the code it seems
to be allowed only as the last component of a pathname i.e.

	/foo/@bar	is valid
	/foo/@bar/	is not valid

and this makes me wonder why one should support this syntax at all,
rather than just using

	/foo/@{bar}

which achieves the same thing, is legal in all contexts, has
a lower chance of conflicting with existing pathnames and
makes the code simpler!

	cheers
	luigi


More information about the freebsd-arch mailing list