Date: Mon, 24 Feb 2003 14:53:24 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224225324.GB1032@athlon.pn.xcllnt.net> In-Reply-To: <3E5A9777.F951598@mindspring.com> References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <3E59E8F4.884C9160@mindspring.com> <20030224100336.GB21088@athlon.pn.xcllnt.net> <3E59F665.DCD54EAF@mindspring.com> <20030224191209.GA559@athlon.pn.xcllnt.net> <3E5A9777.F951598@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 24, 2003 at 02:06:47PM -0800, Terry Lambert wrote: > > > I think people need to fact the fact that i386 is the FreeBSD > > > reference platform, and all other platforms are second class > > > citizens. > > > > Our i386 platform is still the best maintained and supported. > > This however doesn't contribute anything to a possible solution > > other than to indicate that a i386 centric solution at the > > cost of non-i386 platforms is acceptable. I disagree... > > So do I, which is why I believe *everything* should be present by > default, and have to be "commented out" on a per platform basis. I think a scheme to create a couple of buckets and define the inclusion or exclusion based on those buckets generally scales better. We already have that now in the form of MI/MD buckets, but this scheme does not work well, because drivers hardly ever are truly MI and/or truly MD. > This also gives control to the platform maintainer over the decision > of whether or not they are going to make something work on, for > example, the PPC, or if they are going to add a "nodevice" entry to > the /sys/ppc/conf/NOTES file to dike it out -- *only for the PPC*. I think in practice that platform maintainers will base their decision on the busses to which a driver can attach. I for one don't know how else to determine if a driver can work on a particular platform. One might as well use a system that does this by design (or allows this to be done by policy) and thus avoid X platform maintainers (given X platforms) to have to make the deduction manually. > This also supports the philosophy that *you* stated, at one point, > where if something is a PCI driver, it should be present on all > PCI systems, except those it specifically is known to not work on. The condition "if something is a PCI driver" is already a selection that has happened before the "nodevice" filtering. people object to having such an a priori selection and propose a solution on nodevice only. I argue that the preselection is good. I did not state that I reject nodevice as a mechanism to handle the exception, although I did state that nodevice is flawed in that it doesn't deal with options and hints. > If maintaining these per-architecture "nodevice" lists starts to > become cumbersome, then there's an easy answer: attract more > volunteers for that platform, and start fixing the drivers to > make them work, so you can remove the "nodevice" lines. I think this is unrealistic and I think that we only have to look at the current state of affairs and our history (or the history of drivers) to see the proof of it. -- 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?20030224225324.GB1032>