Date: Mon, 24 Feb 2003 14:06:47 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: > On Mon, Feb 24, 2003 at 02:39:33AM -0800, Terry Lambert wrote: > > Marcel Moolenaar wrote: > > > On Mon, Feb 24, 2003 at 01:42:12AM -0800, Terry Lambert wrote: > > > > What they should probably *get* is per machine exceptions, via > > > > "nodevice", which are then correctable on a case by case basis, > > > > instead of having to be corrected globally for all the platforms > > > > all at once. > > > > > > Isn't that's like voting for spam because people can install > > > filters? or like an opt out mailing list: remove yourself if > > > you think you're exceptional? > > > Isn't it also more related to kernel config files where we list > > > devices when we want to add support for them, not to list devices > > > we don't want to support? > > > > No, it's closer to NOT_FOR_ARCHS and ONLY_FOR_ARCHS in the ports > > system Makefiles, such that ports are allowed to be broken for > > particular architectures, where the port maintainer has no way > > of verifying that they actually work. > > > > In fact, it's exactly like that, except instead of a port maintainer, > > we're talking about a driver maintainer. > > I think there's a fundamental difference. NOT_FOR_ and ONLY_FOR_ > are variables set in a ports makefile. To get the list of ports > that could be compiled on a platform, one has to visit each and > every port first. The "nodevice" approach is exactly the opposite. > It's not the driver that tells for which architectures it's meant > to be written, it's the architecture that "rejects" drivers. > The NOT_FOR_ and ONLY_FOR_ approach would work in the kernel as > well. I've left the rest of this because I don't understand your original statement to which I was replying, given this context. If each architecture port of FreeBSD had a NOTES.ppc or whatever file, and it used "nodevice" to remove things from the global case, I don't really see how this differs from the "NOT_FOR_" approach. If each little driver or subsystem like EXT2FS, which was what had been suggested, has it's onl list of architectures that "it supports", then that's tantamount to each driver or whatever being treated as a seperate port, and using the "ONLY_FOR_" approach. What people are objecting to in the proposed "scatter the data over every file in the system" approach is exactly the "ONLY_FOR_" approach. > > 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. 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*. 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. 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. It's really unreasonable, IMO, to expect someone whose life is understanding i386 PC's and some oddball video card to also have to understand the places where Alpha and PPC and ... are different from i386. Not every driver writer should have to become a FreeBSD architecture porting, PPC inline assembler expert (for example). -- Terry 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?3E5A9777.F951598>