Date: Mon, 24 Feb 2003 19:16:41 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224185033.H6037-100000@gamplex.bde.org> In-Reply-To: <20030224064129.GA13290@dhcp53.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Feb 2003, Marcel Moolenaar wrote: > On Sun, Feb 23, 2003 at 10:20:29PM -0800, David O'Brien wrote: > > On Sun, Feb 23, 2003 at 08:02:50PM -0800, Marcel Moolenaar wrote: > > > As I said before, I like the idea. I don't think this is the best > > > separation though. > > > > Unfortunately too many others didn't. > > I have a new patch http://people.freebsd.org/~obrien/sp64notes.diff > > (same name) that uses "nodevice" and sed to remove options. > > I think this is worse: > o devices, options and hints are related in a particular way that > config(8) doesn't handle. Removal of a device automaticly > implies removal of its options and hints. On the other hand, > Removal of hints and/or options does not imply removal of the > device. The "nodevice" approach has no way for config(8) to > honour the relationship and causes pollution and duplication > (such as the sed in the makefile), or worse: conflicts. Sed to remove options is just a hack until config can do it. Hints are of no interest here since they are only for humans to read (they are not stripped by makeLINT.sed). Unremoved options for a removed device are almost as irrelevant (they may be confusing but shouldn't affect the object code). David's sed script has to remove options mainly because they are not present for all arches, not because their device driver is removed. It would be much larger if it removed all irrelevant options. I don't want to deal with configuring perfectly consistent options now (maybe you do? -). I had little success even getting everyone to use orthogonal optional names (like SC_FOO associated with driver sc). > o The addition of a new driver must almost always be accompanied > by a number of nodevice entries for platforms on which the device > does not work, which generally yields a worsed case approximation > (= disabled on architectures the committer is not able to test on). New drivers should just be added to the platforms that it works on or is intended to work on. This doesn't work so well for old drivers because their maintainers aren't all active and there are so many drivers not written with portability in mind, so much so that even drivers that should be portable aren't. > o The list of nodevice entries can get pretty large on some systems. > This pollutes the config file, possibly to the extend that the > nodevice list is longer than the device list. True. I think this is better than putting only the devices that work on all systems in /sys/conf/NOTES. That would essentially regress to the setup before the central NOTES existed, since there are no devies that work on all arches. > In short: I think the nodevice construct is a kludge. Just another > quick and dirty hack that apparently has a high risk of being > promoted to "solution". I agree that it is a klduge. But it is easy to use. I tried setting up some configurations without it and soon found that I needed lots of little files, with nested includes working to avoid duplication (they don't). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030224185033.H6037-100000>