Magic symlinks redux
Luigi Rizzo
rizzo at iet.unipi.it
Fri Aug 22 22:48:45 UTC 2008
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
More information about the freebsd-arch
mailing list