Date: Sun, 28 Sep 2008 23:36:40 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org Subject: Re: dynamic update of usb/pci/quirks tables Message-ID: <20080928213640.GA55310@onelab2.iet.unipi.it> In-Reply-To: <20080928.135855.1708680935.imp@bsdimp.com> References: <20080928100731.GA49323@onelab2.iet.unipi.it> <20080928.135855.1708680935.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080928213640.GA55310>