Date: Mon, 24 Feb 2003 01:48:56 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224094856.GA21088@athlon.pn.xcllnt.net> In-Reply-To: <20030224185033.H6037-100000@gamplex.bde.org> References: <20030224064129.GA13290@dhcp53.pn.xcllnt.net> <20030224185033.H6037-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 24, 2003 at 07:16:41PM +1100, Bruce Evans wrote: > 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). I don't think they will cause problems now, but that does not mean that they could eventually. When it possibly does cause problems at a later time, it's likely much harder to do it right then than it will be now. > David's sed script has to remove options > mainly because they are not present for all arches, not because their > device driver is removed. The advantage of centralized documentation is in my opinion of less importance than the disadvantage of having options listed outside kernel config files (including NOTES), which begs for documentation... > 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? -). Not necessarily right now, but definitely in the end. > I had little success even > getting everyone to use orthogonal optional names (like SC_FOO > associated with driver sc). I think it's the underscore :-) :-) > > 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. I think this is an unrealistic model, because it assumes research, planning and motivation beyond what I think is realistic. The research part is needed to get a good understand of which platforms use (or can likely use) the device, so that the driver can be designed and implemented for that. The planning is required because most of the time the developer has only a subset of the platforms for which the driver can be written and thus needs the help of others and the motivation is needed because the complexity and the work involved is generally much higher. > 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. Given time, this applies to new drivers as well :-) > > 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. Yes, with the addition that it implies something differently for me. I still like the bus-centric approach. A driver that has a PCI front-end should be compilable on any machine that supports the PCI bus. Whether there's actual hardware in existence that works on the platform is not important. Put all the drivers with a PCI front-end in NOTES.pci and you should have a fairly convenient bucket. At this time (I haven't had much feedback yet or run into walls myself) I think that the bus-centric approach yields a good categorization, with redundancy or duplication that has nice (=logic) properties: bus-specific options (and hints) are mentioned in the most logic place. > > 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. It better be. A kludge that's hard to use is more often than not a bug :-) > 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). I think there will be duplication no matter what we do. I think the trick is to find the imperfection that feels natural enough that it isn't perceived as a flaw. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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?20030224094856.GA21088>