dynamic update of usb/pci/quirks tables

[Luigi Rizzo]

Hi Warner,

On Sun, Sep 28, 2008 at 01:58:55PM -0600, M. Warner Losh wrote:
> uscanner_devs and sis_devs aren't quirks.  They are device tables.

i actually also mentioned umass which is definitely a quirks table
(and to tell the truth, uscanner_devs has a flags
field as well, even though it only supports 2 values).

> You've repeated ignored the mapping idea that I've posted.  You can't

I have not ignored the mapping idea -- i explicitly mentioned it
in my email, saying that my suggestion does not handle device
mapping.
   I do like the device mapping idea, i think it is a useful one, but
it is not sufficient, because it doesn't cover the case of quirks tables
(i wouldn't know how to actually implement the mapping thing,
but that's just my ignorance in that area of the kernel - i am
sure i can figure out with some studying).

This said, the kldsym/kmem based approach has the advantage that
it can be implemented as a port (if you forget the /boot/loader support)
and be used on a pre-existing system without having to rebuild kernels
or modules. Some times this can be useful.

> just add stuff to tables randomly and expect that to work (says
> someone who has actually done this to lots of drivers in the tree in
> the pccard era).  the driver has to know what kind of device to treat
> it as.

i don't understand why you believe that i am suggesting to
"randomly adding stuff" to the tables.

I know (and I wrote it in my email) that playing with tables is
dangerous and one should know what he is doing before trying.

Certainly, if i have a device with unknown specs, the only way to
tell what it can do is by trial and error, looking at a similar
devices, and playing with mapping or quirks tables.
Sure, if the code itself outside the table makes use of
the actual IDs, then adding entries to the tables may not work.

But, if and when someone has determined that the patching is safe
(e.g. because it is a quirks table, as in the umass case, or because
the actual IDs are not used anywhere else in the code, as in the
case of uscanner or if_rl or probably many other places), I don't
understand why we should artificially make life harder to FreeBSD
users asking them to "upgrade to next release" or "patch and rebuild
the kernel".  Sometimes you just can't do that -- take e.g. the
case of embedded platforms where you don't have a compiler available
or possibly not even full kernel sources -- after all it's BSD licensed!

> Putting a translation table into the kernel is much easier and you
> don't have to worry about hokey kludges like what you describe with
> 'patch'.
> 
> Maybe it will work out for the other tables you want to update, but it
> won't work well for device tables.

I am open to all solutions that can make FreeBSD more compatible
with external hardware. It will be great if we can implement your
mapping idea. It will be great if there is a better way of handling
quirks tables.

	cheers
	luigi