From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 9 23:01:55 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 797D116A4CE for ; Fri, 9 Jan 2004 23:01:55 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B21F43D4C for ; Fri, 9 Jan 2004 23:01:53 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 79911 invoked by uid 1002); 10 Jan 2004 07:01:51 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 10 Jan 2004 07:01:51 -0000 Message-ID: <3FFFA2F9.3040707@freebsd.org> Date: Sat, 10 Jan 2004 00:00:09 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy 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> <20040110065054.GS25474@server.vk2pj.dyndns.org> In-Reply-To: <20040110065054.GS25474@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Dag-Erling Sm?rgrav cc: hackers@freebsd.org cc: "Matthew D. Fuller" 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 07:01:55 -0000 Peter Jeremy wrote: > 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 > Right, since there are at least 5 identifying fields in the PCI config space that might need to be looked at. Lets not repeat the mistakes of vendors like RedHat that require that a duplicate table be maintained (with only 2 of the five fields!). Whether our tables are generated through script magic or through a stuctured API doesn't matter so long at it adds minimal burden to the driver maintainership and is guaranteed to always be in sync. Scott