Magic symlinks redux

[Luigi Rizzo]

On Fri, Aug 22, 2008 at 10:51:27AM -0500, Brooks Davis wrote:
> On Fri, Aug 22, 2008 at 05:46:31PM +0200, Luigi Rizzo wrote:
...
> > Do you know how much of it is used to implement the "varsym"
> > subsystem (user- or system-wide variables) and how much is the
> > core name translation ?
> 
> Most of it is maintaining the lists of variables, handling the system
> calls to read and write them, and doing the lookup with the correct
> locking context.  The basic match routine is about the same size, though
> if you get a hit it's somewhat more expensive since you have to walk up
> to three lists (two in what's in p4 at the moment, but I'm currently
> splitting the per-proc code into privileged and un-privileged sets to
> the administrator can add values to processes that later owners can't
> modify) to resolve the variable name.

so if i understand it well it could be committed as two separate
pieces: one for the lookup and translation itself, and one for
the variable management.

The split would be very interesting for at least two reasons:
1. ease of porting/backporting/modularization e.g. think of
   the embedded case where one might want a limited or even no
   form of symlinks to save memory

2. maybe the code in charge of variable management can be replaced
   with some simpler instances (again for the embedded case, or e.g.
   to implement the NetBSD version of variant symlinks),
   reused for other purposes, or perhaps also integrated with other
   existing implementations.

In fact i wonder about the following:

we already have code to deal with kenv and sysctl,
this would be a third mechanism that does a very similar thing,
isn't there anything we can recycle from the existing ones ?

Also, we do have a need to push tables of info in the kernel
(e.g. list of PCI/USB ids, quirks tables and the like),
maybe we can take this chance to make the varsym subsystem useful
also within device drivers ?

	cheers
	luigi