Date: Thu, 1 Feb 2007 16:13:02 -0500 From: John Baldwin <jhb@freebsd.org> To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-arch@freebsd.org Subject: Re: configurable device (and other) tables in the kernel ? Message-ID: <200702011613.02809.jhb@freebsd.org> In-Reply-To: <20070201091605.A82313@xorpc.icir.org> References: <20070131115148.A60420@xorpc.icir.org> <200702011109.12821.jhb@freebsd.org> <20070201091605.A82313@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 01 February 2007 12:16, Luigi Rizzo wrote: > On Thu, Feb 01, 2007 at 11:09:12AM -0500, John Baldwin wrote: > > On Wednesday 31 January 2007 14:51, Luigi Rizzo wrote: > ... > > > We have several tables in our kernel and modules, > > > containing at least device-id tables (pci, usb), > > > quirks for certain devices, and maybe more (i am excluding > ... > > Windows and MAC OS X both use plain text files to hold things like PCI device > > IDs to match drivers to devices. OS X uses an XML file format that lets you > > plain text files! > > too obvious to think of it :) > > but, where can i find an example of a piece of kernel code that can > read from a file "safely" (i.e. say in the modevent handler or maybe > at device probe time) ? > Something like > > char *load_file_into_kernel_memody(filename, max_size, &error); > > I have looked at the kernel side of execve and kldload, they are not > exactly straightforward (at least there are seveal indirections). > Maybe there are other simpler ones ? I think this would be a bad idea (kernel loading files). I think instead you should depend on userland to hand stuff to the kernel. For example, if you want to autoload drivers, you should have some sort of database devd consults to find a driver to kldload to see if it attaches to the device. > > list the PCI ID's a driver supports and the kernel auto-loads driver modules > > by matching on PCI IDs. Many drivers can't be helped by this though, as they > > use the device ID for for device-specific behavior (such as em(4) or > > brgpy(4)). > > well, that's a two-phase process, if you have the above table-based > mechanism, the kernel (actually the bus driver i would say) can > load the [device_id -> driver] table (or tables, assuming > each driver has its own file) to select and load the > correct driver, and then the driver itself could use the same > mechanism to load a [device_id -> quirks] table for internal use ? You missed the much more glaring problem. Suppose a new device comes out, and you want to add support to it to an existing driver, so you add the PCI ID of the card and load the driver. Only, since there's no _code_ to handle the quirk (think about the case of a quirk that didn't exist before), then it doesn't work, or worse, it sort of works until it hoses a bunch of data. I really don't think this is a good idea. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702011613.02809.jhb>