On Wed, Apr 26, 2006 at 08:07:08PM +0100, Rui Paulo wrote: > Quentin Garnier <cube%cubidou.net@localhost> writes: > > > On Wed, Apr 26, 2006 at 06:36:26PM +0000, Rui Paulo wrote: > >> > >> Module Name: src > >> Committed By: rpaulo > >> Date: Wed Apr 26 18:36:25 UTC 2006 > >> > >> Added Files: > >> src/sys/conf: lint.cardbus lint.compat lint.fs lint.isa lint.mca > >> lint.misc lint.net lint.pci lint.pcmcia lint.usb lint.wscons > >> > >> Log Message: > >> Add work in progress lint files that will be used by port specific > >> LINT kernel config files (will be added later). > >> The list is far from complete and there are some missing files, busses and > >> devices. > > > > I like the idea of having a LINT kernel (or some way to obtain it), but > > those files strike me as the wrong way to do it. > > > > I'd rather see config(1) generates a LINT file with all possible > > options stuffed in. It is foolish to expect people to maintain this > > bunch of files sprinkled all around the tree. > > > > LINT will not be meant to be booted, so config(1) may very well > > generate it, issueing starred instances definitions for all devices it > > finds, even though it makes little sense (and just plain doesn't work) > > for ISA devices and the like. The point is to compile every possible > > driver for a given arch, so config(1) ought to parse everything and > > spits out the resulting configuration. > > > > I'm willing to help with the details, but I really object to those > > lint.* files which will rot faster than it takes to write them. > > Ok, some topics: > * config(1) has no way of knowing about the conflicting options > (normally they are hardcoded in the .c file with #error's -- as > you know I proposed some a way to fix this PR #32714) Yes, that's an issue. Note that #32714 addresses the dependency issue, not the conflicts. Generally speaking, conflicting should be avoided: pacific co-existence is made possible in the extreme cases by making one take advantage over the other through #if magic, otherwise you'll need a _lot_ of LINT kernels to cover all cases. Requisites are not a problem when config(1) auto-generates a LINT configuration. > * config(1) can easily generate output for devices that are in > "autoconfigurable" busses like PCI, ISA-PnP, etc. but has no way > to output the exact configuration for ISA for example (port, irq, > iomem, etc.) At this point you have to precisely define what LINT is supposed to be. I don't see it as something you would boot, it's just impossible to consider it. As I see it, its purpose is to compile as much as possible to prevent rarely used drivers from rotting, and so on. Therefore, locator values are of little interest. config(1) knows about locators that require a value to be set, and using 0 will just do fine for that purpose. Note that it also means conflicting options are less of an issue, too, because usually they will conflict on a semantic issue, yet still be compiled together. LINT doesn't have to make sense as a kernel configuration. > * can config(1) generate pseudo-devices for file-systems too ? Do you mean like file-system SMBFS vs. pseudo-device smb? The point is to have everything included, so both will end up in the generated LINT. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "When I find the controls, I'll go where I like, I'll know where I want to be, but maybe for now I'll stay right here on a silent sea." KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
Attachment:
pgpKUs2aNUzex.pgp
Description: PGP signature