Subject: Re: Managing MI entries in our GENERIC-like files
To: Gavan Fantom <gavan@coolfactor.org>
From: David Brownlee <abs@netbsd.org>
List: tech-misc
Date: 06/26/2004 14:09:56
On Sat, 26 Jun 2004, Gavan Fantom wrote:
> On Sat, 26 Jun 2004, David Brownlee wrote:
>
>>> Having something that spits out a full config file (w/ no includes) that
>>> can then be edited would be nice.
>>
>> so that would be option 2 - have a GENERIC.in which creates
>> a GENERIC, both of which are checked in? Or just an option to
>> config which resolves all includes and spits out the result
>> (I'm prefer not the latter :)
>
> While we're here, I'd quite like to see something a bit more like our
> rc.conf, where you can explicitly specify the things you care about, and
> leave the rest to defaults.
>
> This would be especially useful if you could say, "no pcmcia", and leave
> config to figure out that anything hanging off pcmcia therefore shouldn't
> be included.
I believe config can already handle orphaned devices.
> Ideally I'd like to be able to specify something along the lines of:
>
> # busses not present in the machine
> no pcmcia
> no cardbus
> no scsi
> no randomfooblah
>
> # only need driver for one network card
> no devices network
> rtk* at pci*
>
> # only need driver for one sound card
> no devices audio
> eap* at pci*
> # perhaps audio* at eap* would still be needed here?
We could do something like like having a GENERIC.in with
m4_define(`bus_pci', 1)dnl
m4_define(`bus_usb', 1)dnl
m4_define(`bus_eisa', 1)dnl
m4_define(`devices_pci_network', 1)dnl
m4_define(`devices_pci_audio', 1)dnl
m4_define(`devices_pci_scsi', 1)dnl
m4_define(`devices_pci_raid', 1)dnl
m4_define(`devices_pci_pciide', 1)dnl
m4_include(`../../../conf/devices.conf')dnl
devices.conf contains all MI busses and devices, with
appropriate m4 tests.
The bus_* defines would include the MI usb@pci, eisa@pci etc
attachments.
devices_<bus>_<type> would include all devices of that type
I've had a pass through the devices from i386 GENERIC and I
cannot get a result with which I'm happy.
> This would be much more likely to be upgrade-proof than the existing
> scheme of copying GENERIC, editing it and trying to merge in changes.
Possible for that usage a better option would be to add code to
config.
The decision on the use of m4 vs cpp is in somewhat of an astable
state at the moment...
--
David/absolute -- www.netbsd.org: No hype required --