Date: Mon, 24 Feb 2003 02:39:33 -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: <3E59F665.DCD54EAF@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 people need to fact the fact that i386 is the FreeBSD reference platform, and all other platforms are second class citizens. The onus of supporting a port (or a driver) on an architecture that the port (or driver) maintainer doesn't have readily available to them for testing needs to be on the proponents for that architecture. PS: The whole idea config adding/removing support for devices is really very bogus, and has more to do with lacking ELF section attribution for code, data, probe code, probe data, paging path, non-paging path, etc. (all of which Microsoft readily supports in their OSs, via PELDR, and which GCC can also support through section attribution), than it has to do with any real technical argument to the contrary. The "config" program should die. PPS: Both Julian and Poul have spoken eloquently and at length about not varying the size of kernel structures based on compilation options in the config files. Their arguments are made on the basis of module options not matching kernel options, but the same argument applies to the ability to both statically and dynamically link the same object files, and the ability to use an ELF archiver to add/remove modules in an already compiled kernel (the main effort that this entails is editing the linker set contents for SYSINIT() created linker sets; if they are sectioned properly, then you don't care: you just regenerate them). The config program should die. PPPS: The config program should die. -- 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?3E59F665.DCD54EAF>