Magic symlinks redux

[M. Warner Losh]

In message: <20080822214118.GA64725 at onelab2.iet.unipi.it>
            Luigi Rizzo <rizzo at iet.unipi.it> writes:
: > Also, this problem isn't just replacing a table in the kernel.  The
: > problem is "map this ID to that ID" because many drivers do special
: > things for different IDs, and you have to specify the ID that it is
: > compatible with.
: 
: 
: what's wrong with something like this
: 
: 	driverparms.if_re.devid.0x11864300 = "0x04000000 D-Link DGE-528(T) Gigabit Ethernet Adapter"
: 	driverparms.if_re.devid.0x11868139 = "0x74800000 RealTek 8139c..."
: 	...
: 
: The subtree under if_re only needs to be known to the device, though
: some standardization would help of course -- e.g. we could have generic
: code to parse device ids of variable size using wildcards, and for
: the value field we could use xml encoding (if something more trivial
: does not fit -- but a barebone xml parser such as the one we need here
: fits in 5-10k of object code, i did that a few months ago , see
: 
: 	http://info.iet.unipi.it/~luigi/FreeBSD/minixmlrpc/
: 
: Hooking a write callback on a node, e.g. to driverparms.
: if_re.devid would allow the driver to update its own internal
: table of descriptors upon a change, and retain the current match
: code (and speed) essentially unchanged in all drivers.

You're going to have to give me a much more detailed description than
this, because the driver getting a callback to update its information
is very handwavy.  And drivers wishing to do this would need to do a
lot of work to make sure that their tables are dynamic.  Today, they
are static, or in code (eg, switch statements).  this sounds like a
very complex solution to the problem, without really a clear vision
for how it would draw together different devices.

: > : linux has a way (forget what the command name is) to add entries
: > : to the table at runtime, whereas on freebsd
: > : we need to patch&rebuild the module.
: > : 
: > : if make this 'object store' thing (varsym) able to store arrays we
: > : could have device drivers scan the arrays (e.g.  uscanner_id or
: > : if_rl_pciids etc.) to find out if it has a suitable string.
: > 
: > That's the wrong way to solve the problem.  In FreeBSD there's no
: > universal table on any bus except for PC Card.  Until we have that,
: > this solution can't happen.  Each driver has its own ad-hoc way of
: > doing this.  Even in PC Card land, the size of the table isn't
: > exported.
: > 
: > The way that drivers are written today in FreeBSD, the bus has to
: > provide this translation layer.  There's really no other viable
: > solution.  If someone goes through and fixes all the important busses,
: > then maybe this would be a needed service.
: 
: perhaps you are pointing to an ideal solution, which however would
: still require significant work on each driver to adapt the current,
: ad-hoc tables to the solution supplied by the bus.
:
: The approach i suggest above allows incremental deployment and i believe
: it still scales well.

Actually, the solution that I propose requires *NO* changes to any
leaf drivers.  None.  It only requires changes in the bus level code
to do the lookup and substitution.  They are totally ignorant of the
changes that are going on behind the scenes and can treat a new card
just like a card they already support without even knowing that they
are doing this.

Since I don't understand your suggestion at all, I can't comment about
how well it scales.  From what I see, it is a disaster in that area as
every driver that wants to participate in this would need to change.

Warner