Date: Tue, 16 Dec 1997 07:52:31 -0300 From: daniel_sobral@voga.com.br To: tlambert@primenet.com Cc: hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <8325656F.0038C91F.00@papagaio.voga.com.br>
next in thread | raw e-mail | index | archive | help
> The existance of mutually exclusive drivers is not friendly. Agreed. But do not forget that mutual exclusion is not the only thing being discussed here. You said prerequisites are not useful either. > 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. This may not always be fixed, as far as legacy hardware goes. > 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? Since you disregarded my RL examples as "will be fixed in the future", I'll bring something from the future to haunt you... :-) FreeBSD creates a driver for device X. Third-party commercial vendor creates another driver for the same device X. Thus, you cannot help but say "hey, use _this_ driver instead of the other one". Now, just so you don't forget, below we discuss mutual exclusions _and_ prerequisites. > > 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. That is not the point. We use your solution to deal with "legacy" code that has not been "fixed" yet (assuming this is at all possible), and then we stumble on some other "mutually exclusive options" that _cannot_ be solved the way you proposed. We create the "mutual exclusion" structure to solve that problem, and end up with two different structures being used to solve the same problem. See 1) above. As for "binary", I haven't said "binary", I haven't _thought_ "binary". When I say "structure", forget C's "struct". Structure as in "directories is a structure". > > 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. Not at all. First, you have yet to show me that we can do without some kind of "what devices/features I want to be loaded/probed" configurator. I *don't have* PCI on my FreeBSD computer, so it is very easy for me to ignore any suggestion that precludes non-PCI hardware. Second, I am not coding anything. Somebody else is, and this somebody choose to deal with the problem at this level. I'm just making suggestions in the hope that he won't screw up in the process he has choosen to deal with. > > 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?!? Elf? You said "rc.conf". You were talking about using sections instead of prerequisites to deal with the "history buffer only with syscon" problem. So, you propose a solution that does not deal directly with the problem, by stating explicitly "this only if that", which has potential problems as shown above, and say your solution has historical precedent, exemplifying with rc.conf. Terry, it would be more productive if you choose one of the two solutions you proposed: 1) Don't. Kernel configuration should go away. (In this case, just stay away from the discussion, as it's about kernel configuration, like it or not) 2) Use this and that. (In this case, deal with the issues at hand instead of directing problems to your solution to 1) > > 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". That's a valid point of view, though I think it is flawed. Anyway, if that's your opinion, why are you discussing how the kernel configurator file should be structured?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8325656F.0038C91F.00>