Date: Mon, 15 Dec 1997 20:17:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: daniel_sobral@voga.com.br Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <199712152017.NAA15154@usr07.primenet.com> In-Reply-To: <8325656E.00652DC2.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 15, 97 03:42:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> And that's supposed to be user friendly at the same time, right? > > I'm talking about what the kernel configuration file must have so that a > user friendly configuration tool can be created. And, as far as I am > concerned, ordering is not user friendly. The existance of mutually exclusive drivers is not friendly. There are two types of exclusion: 1) Screw up: the driver probes are antagonistic to other hardware. This should be fixed by changing the probe code. 2) Screw up: there is more than one driver for the given hardware. This should be fixed by integration. Your console example falls into #2, and Johnathan Mini is working on fixing it. Do you have other examples? > > A data section groveller would allow you to set this type of thing; > > we currently have three of them, counting sysinit/rc.conf. > > That would kind of work. Except... that structure does not have the > semantic content for which it is being used, meaning that: > > 1) If the need later arises for the correct structure, we'll be left with > the choice of modifying *all* previous structures to the correct one (and > we all know how hard such things are), or using two different structures > for the same end. This is why there needs to be an extensible schema mechanism (like that of LDAP) instead of a binary structure based mechanism for doing this sort of thing. This is why God invented Directories. > 2) It may lead to pilot error. Detachable power cords lead to pilot error. Eventually, you have to cut your losses below a certain level of complexity. Your problem with this seems to be that BSD isn't below that line. I think a kernel configurator will just prop up the existing bad situation, and delay more correct change. > 3) It's a hack and should be banned to hell. > > Terry, are you suggesting a backward compatibility hack (with tradition, > not even code!) instead of doing the right thing??? "Backward compatability hack"? ELF archiver? What ELF system are *you* running on?!? > > There's no need for a build-time configurator, in any case. > > You mean there won't be no need for a build-time configurator if and when > we get to the perfect world, right? Because, right now, I can't seem to get > along without config... And the more you enhance it, the less likely that people will do anything about moving the code forward in this area. "Good Enough" is the enemy of "Better". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712152017.NAA15154>