configurable device (and other) tables in the kernel ?

[John Baldwin]

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