Date: Sat, 3 Feb 2007 11:57:59 -0800 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org Subject: Re: configurable device (and other) tables in the kernel ? Message-ID: <20070203195759.GG779@funkthat.com> In-Reply-To: <20070201.110206.1102529050.imp@bsdimp.com> References: <20070131115148.A60420@xorpc.icir.org> <200702011109.12821.jhb@freebsd.org> <20070201091605.A82313@xorpc.icir.org> <20070201.110206.1102529050.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote this message on Thu, Feb 01, 2007 at 11:02 -0700:
> 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.
Hmmm.. couldn't we do something like dedicate a section to a simple
table that contains the PCI id's and related data to match.. Then
we could have a tool that embeds the PCI id data from a plain text
file and recreates the plain text file from the section...
This doesn't solve the cases where the driver needs to handle a device
specially, but w/ the text file, and the driver using the table, it'd
be easy to do an on demand load pass... (and for new devices, users
would be able to test drivers w/o having to recompile the module)..
And as part of installation, it lists the modules that are necessary
to boot in loader.conf...
Just a thought...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070203195759.GG779>