Magic symlinks redux

[Luigi Rizzo]

On Fri, Aug 22, 2008 at 04:01:07PM -0600, M. Warner Losh wrote:
> In message: <20080822214118.GA64725 at onelab2.iet.unipi.it>
>             Luigi Rizzo <rizzo at iet.unipi.it> writes:
...
> : 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.

take if_re as an example. When if_re loads, it would call

	object_store_register("driverparms.if_re.devids",
		if_re_update_devid_table, if_re_devid_table_root);

which in turn puts the string-function-arg tuple in a hash table
using the string as a search key.
Optionally, it could also call a routine to pre-fill the
object store subtree with static content supplied by if_re.c or so.

When (from the upper part of the kernel, so it can sleep etc.) the
subtree is written to, the object store calls
	if_re_update_devid_table(if_re_devid_table_root)
which in turn would scan the subtree using the api
supplied by the object store itself, and rebuilds the table, quirks,
whatever used by if_re for its own purposes.
Clearly, this is specific for if_re. umass will
likely have a more complex structure with quirks etc,
uscanner is just a table of device ids, etc.

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

...

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

sorry but now i am the one who doesn't understand how you can move,
with *NO* changes to the leaf drivers, from a bunch of drivers using
ad-hoc solutions (static tables with variable number of fields, or
lookups hardwired in the code, which don't use just the vendor/device
fields but also other info e.g. subdevice as in if_re) to one that
relies on the bus code for the matching.

At the very least you need to replace the part of the *_probe routines
with something that uses the bus routines -- and implement something
that lets you manipulate the mapping/quirks table at runtime
so that if a compatible device with different IDs comes out
you don't have to recompile and reload a module.

That's the same kind of changes that I expect to be necessary with the
way I have in mind.

i am sorry i cannot expand this more as i am about to leave for
holidays, but will try to come up with some proof-of-concept code
when i am back.

	cheers
	luigi