Date: Tue, 16 Dec 1997 18:47:57 +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: <199712161847.LAA18094@usr01.primenet.com> In-Reply-To: <8325656F.0038C91F.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 16, 97 07:52:31 am
next in thread | previous 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. No. I said prerequisites could be automatically handled by the KLD code, and so they are not necessary to specify in a kernel config. This is very different than say they are not useful (frankly, with the number of appeals I've made for graphical soloutions to problems, I'm surprised you could even think I meant that ;-)). > > 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. So far, it's always been fixable with probe order. Probe order can be specified using a priority field in the data in the driver image itself, and doesn't require a config file (or us one, in fact; the priority for the LANCE probe in the GENERIC image, for example). > > 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. The order of operation is dictated by the initialization order preference data. For your example of a third party driver to replace a FreeBSD driver, the obvious answer is to give the third party driver a higher priority. If present, it will get to the hardware first, and the FreeBSD driver's probe will fail, and it will be unloaded. > 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". The idea that a structure change could not be forward compatible is what implied binary. If it's not binary, then a correct design wll *always* be forward compatible. Look at the sysinit_sub_id values for the order field in the file /usr/include/sys/kernel.h. When I first wrote the SYSINIT() code, this is exactly the problem I was attempting to solve. I believe I *did* solve the problem. > > 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. This is an easy answer. You load all drivers for which their probe routines in their ELF init sections probe "true". Period. If you don't want to actually use the devices, then don't open their /dev entries. But you don't get a choice about the driver. If the driver is not boot critical, and you don't want it loaded (ie: an embedded system with a sound chip on the board but no speakers attached, etc.), then don't put the module binary into the directory where the kernel looks for module binaries. This handles the "need/want to be loaded" cases. Your kernel configurator is /bin/ln, /bin/rm, and /bin/cp. > 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. Well, fine. But the concept of needing a kernel configurator itself is what's flawed, and any suggestions about "what kind is needed" are compounding that. I'm just pointing that out in the hopes that someone will not make it their life's work, only to find it dead on arrival, since I expect these ELF dependent facilities to appear "soon". > > > 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". ??? I think you have the wrong person. I think rc.conf is an abomination before God. For one thing, it lives in a directory which, in my ideal world, is mounted read-only. So you wouldn't be able to "conf" the thing anyway. > You were talking about using sections instead of prerequisites to > deal with the "history buffer only with syscon" problem. Well, I think you don't need to tune the syscons buffer the way you are presenting tuning it. I think that if it's a tunable, it should be a runtime tunable, and you should be able to access it via a persistant MIB. A directory. If this is what got you confused about rc.conf (many sysctl "MIB" tunables persistance are kludged by existing in rc.conf now), then you misaprehended me. > So, you propose a solution that does not deal directly with the > problem, by stating explicitly "this only if that", Yes. > which has potential problems as shown above, No. Makefiles deal with these dependencies every day. It's called a topological sort. > and say your solution has historical precedent, exemplifying with rc.conf. No, exemplefied with "make", "tsort", "LDAP", the Windows NT and Windows 95 registries, AIX, and NeXTStep's niload/nidump (this last's failure of the "netinfo" mechanism derives from trying to make flat files available at the same time without providing "vipw"-like wrappers through which they must be editted. > 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) Fine; but don't expect that the resulting code will be useful or used in the near future when it becomes possible for us to dynamically load kernel components, and to discard potentially boot-critical drivers which are not in use. > 2) Use this and that. (In this case, deal with the issues at hand instead > of directing problems to your solution to 1) Well, I presented my persepective on a framework in which a kernel configurator is not necessary. That's the future I advocate. This means that I oppose projects whose assumptions preclude such a future. You can't expect me to not be vocal in this opposition. The further you go down the wrong road, the harder it's going to be to backtrack. > > 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? I haven't. I've only discussed how the problems you are attempting to solve via a kernel configurator should be solved instead, so that they require less user intervention, and do not violate the principle of least astonishment. I'm only voting, for cases where you require explicit dependencies, that those dependencies aren't routed through a human being running a kernel configurator to be resolved. 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?199712161847.LAA18094>