Date: Thu, 01 Feb 2007 11:02:06 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: rizzo@icir.org Cc: freebsd-arch@freebsd.org Subject: Re: configurable device (and other) tables in the kernel ? Message-ID: <20070201.110206.1102529050.imp@bsdimp.com> 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
In message: <20070201091605.A82313@xorpc.icir.org>
Luigi Rizzo <rizzo@icir.org> writes:
: 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 ?
Look at the firmware routines. However, they won't work until / is
mounted, which is after all the device probing happens.
: > 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 ?
On the one hand, I like the flexibility of having the ability to look
at a device and know what driver(s) may attach to it w/o having the
drivers in memory, since that allows us to move to a demand load
model for those people that want it. Right now, there's no way to
smartly extract the plug and play info used by the device probe
routines to bid on a device from the drivers to try to smartly load,
say, the atheros driver when an atheros cardbus card is inserted.
However, only pccard and miibus drivers seem to religiously use tables
to do their configuration. No other busses do that currently,
although many have support for doing so. usb and pci are the big
offenders whereby the probe is handled in many ad-hoc hackish ways.
usb is bad in another way: it doesn't grok reprobing and has a
'vacuum' device that attaches to everything (ugen). The other issue
is that there's many different parts of the PnP information that are
used to bind devices to drivers. In pccard, for example, sio doesn't
have a list of all modems, but instead attaches to all serial cards
based on function id rather than the typcial vendor/model identifiers
that other drivers use. This multiplicity of selection methods
complicates any solution.
On the other hand, the reason that we have the device driver tables
compiled into the kernel is because when the kernel is doing its
initial probe/attach of devices, it can't touch the root file system.
This is the classic chicken and egg problem. The loader would have to
assist the kernel in loading these tables, but there's complications
for situations where one is booting over the network, or one is
booting from flash. In these situations, it can be impossible to load
another module until more of the infrastructure is in place (either
disk drivers + busses + cam/ata or nfs + network interface).
I've long wanted to have the ability to tell a bus to 'pretend' that
the device ID for a given device is XXXX rather than the YYYY read
from the device's enumeration mechanism. This would allow us to
'quirk' drivers for new hardware, as well as allow for users to get
their devices up and running more quickly than having to rebuild the
kernel. While this is the safest solution, it doesn't solve the
'which module to load' issue. It also doesn't force users to report
these device IDs back to us, which may make fewer devices work out of
the box in the long run. There's also only so much one can do with
this mechanism if the driver is smart and has workarounds for
different models and such that aren't needed/are harmful to newer
silicon.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070201.110206.1102529050.imp>