Date: Sat, 23 Aug 2008 00:51:19 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: "M. Warner Losh" <imp@bsdimp.com> Cc: brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux Message-ID: <20080822225119.GA65119@onelab2.iet.unipi.it> In-Reply-To: <20080822.160107.511563083.imp@bsdimp.com> References: <20080822193657.GB63527@onelab2.iet.unipi.it> <20080822.141312.732640662.imp@bsdimp.com> <20080822214118.GA64725@onelab2.iet.unipi.it> <20080822.160107.511563083.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 22, 2008 at 04:01:07PM -0600, M. Warner Losh wrote:
> In message: <20080822214118.GA64725@onelab2.iet.unipi.it>
> Luigi Rizzo <rizzo@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080822225119.GA65119>