From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 9 22:51:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8684416A4CE; Fri, 9 Jan 2004 22:51:12 -0800 (PST) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B18343D54; Fri, 9 Jan 2004 22:51:10 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])i0A6p07B059279; Sat, 10 Jan 2004 17:51:00 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.10/8.12.10/Submit) id i0A6ossr059278; Sat, 10 Jan 2004 17:50:54 +1100 (EST) (envelope-from peter) Date: Sat, 10 Jan 2004 17:50:54 +1100 From: Peter Jeremy To: "Matthew D. Fuller" Message-ID: <20040110065054.GS25474@server.vk2pj.dyndns.org> References: <200401091400.40550.doconnor@gsoft.com.au> <3FFE5211.5040606@freebsd.org> <20040109.075929.90380697.imp@bsdimp.com> <20040109210153.GP25474@server.vk2pj.dyndns.org> <3FFF1BEE.9090400@freebsd.org> <20040109222654.GS48603@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109222654.GS48603@over-yonder.net> User-Agent: Mutt/1.4.1i cc: Dag-Erling Sm?rgrav cc: hackers@freebsd.org cc: Scott Long Subject: Re: Discussion on the future of floppies in 5.x and 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 06:51:12 -0000 On Fri, Jan 09, 2004 at 04:26:54PM -0600, Matthew D. Fuller wrote: >On Fri, Jan 09, 2004 at 02:23:58PM -0700 I heard the voice of >Scott Long, and lo! it spake thus: >> Dag-Erling Sm?rgrav wrote: >> > >> >yes, we need something like >> > >> >struct pci_device_info { >> > uint32_t pciid; >> > char brand[64]; >> > char model[64]; >> >} my_supported_devices[] = { >> > { 0x12345678, "Acme", "Nutcracker 2000" } >> >}; >> > >> >which is placed in a separate ELF section so we can extract it from >> >the module. >> > >> >except it needs to be flexible enough to support other buses than PCI >> >(SBUS, USB...) >> > >> >DES >> >> Yeah, this is a good suggestion, the only problem being in making it >> flexible enough to not be a burden on the drivers. Many drivers >> keep one or more flag elements in their tables to flag hardware than >> needs special attention. I'm sure that there are also countless other >> pieces of state that drivers would want to associate with a table like >> this. > >I was poking around a bit (in my completely kernel-fu-lacking way) at >this last night. For one thing, we could avoid the struct definition, >and instead just mandate a few fields in the structure with given names >as above. Then, write a little helper .c file with a main() that goes >through the array (with the name given as a preprocessor -D or something) >and spits the info out into a text file. Compile it up and run it for >each module as we compile it, and assemble the results in a big reference >file. Then, a userland program (like sysinstall, in this case) can >easily poke through that text file to find and describe the drivers for >devices found. This is more what I was thinking in terms of. As well as the PCI ID and brand/model, we probably would need: - a priority field, so a generic driver can grab a device if a more specific driver isn't found - the option to use card ID instead of chip ID - wild-carding (maybe a bitmask) And this still isn't enough to identify things like the Realtek 8139C+ chips that would prefer re(4) instead of rl(4) (though rl(4) is good enough to install FreeBSD). Peter