dynamic update of usb/pci/quirks tables

[M. Warner Losh]

In message: <20080928213640.GA55310 at onelab2.iet.unipi.it>
            Luigi Rizzo <rizzo at iet.unipi.it> writes:
: 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).

True.  The umass stuff is definitely quirk table expansion.

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

I posted diffs that did everything except the maintaining the table in
like 15-20 lines of code for PCI.  The hard part is the interface to
/boot/loader and any desire to tweak the table and rescan devices...

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

I doubt that this is a good selling point.  It is rare that you add
new hardware to a system that's already running that's compatible with
the old hardware, but needs updated driver support.  I'm skeptical
that the kld solution would be robust enough for people who have such
situations to trust more than a source rebuild to pickup the new
mapping table.

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

I guess we're saying the same thing: This is a large caliber gun that
can be useful, but also has an unusually high foot-shooting potential.

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

Correct.  This is what I do with PC Card and PCI drivers when I find
hardware at garage sales that I can find no other data on.  Usually a
model number and version will get me enough data to know.  But
wireless cards seem to have busted that :-(.

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

I think the embedded argument oversells the capability here.  It
assumes the embedded systems let you get to the boot loader prompt, or
that it even uses /boot/loader.

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

Let's pursue both ideas.  I'll implement it for usb, pci, pc card and
cardbus and we'll see where it goes.

Warner