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>