Date: Tue, 11 Dec 2001 13:14:54 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Warner Losh <imp@harmony.village.org> Cc: "Erik H. Bakke" <ebakke@trolltech.com>, "Sheldon Hearn" <sheldonh@starjuice.net>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb usbdevs.h usbdevs_data.h Message-ID: <200112112014.fBBKEsg72815@aslan.scsiguy.com> In-Reply-To: Your message of "Tue, 11 Dec 2001 13:05:43 MST." <200112112005.fBBK5hM29790@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>In message <200112111822.fBBIMxg69086@aslan.scsiguy.com> "Justin T. Gibbs" wri >tes: >: All that this central database does is prevent you from shipping a >: binary module for a new device and have it be properly announced >: unless you have a new usb core module too. Just put these entries into >: the individual drivers and have them call a common routine in the USB >: code to export the entry on attach. > >Yes. That's true. You don't have to have them in the central >database. I'm not sure why we have the central database array in the >kernel, since we did eliminate it for the pccard side of things. The >generated .h files provide a common and convenient way to do the USB >device stuff. It also makes sharing with NetBSD easier. We do a fair >amount of device list sharing with NetBSD on the pccard side of >things. I guess I don't see a large benefit to sharing IDs with NetBSD so long as they insist on a clunky global list generation of IDs. If I'm a third party creating a binary only module, my IDs and table entries are not going to be in that list. I have to be able to do everything from within my module and perhaps self contained source tree I use to build that module. >: Matchin usb devices certainly looks to be as simple as PCI. From >: if_aue.c: > >For aue it is. There are some devices I'm told that you need to look >at the vendor strings themselves. I know that's true for pccard >because vendor's CIS have varied wildly over time. Which just goes to show you that generic code cannot handle every device, so we should export the tools to the modules and let them figure out the best way to probe for their device. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112112014.fBBKEsg72815>