Date: Wed, 17 Dec 1997 08:23:33 -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: <83256570.003AE6C5.00@papagaio.voga.com.br>
next in thread | raw e-mail | index | archive | help
> 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 ;-)). Well, I was surprised you seemed to say that. > 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). [and] > 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. How do you propose I do that? Go around on /whatever, using whatis and mv to remove unwanted files*? I'd rather use a graphical tool. And that's the whole point. At *some* point in the process, I _must_ have the _option_ of choosing what goes in and what stays out of kernel, no matter when or how that thing is loaded. It would be nice to have a nice-looking tool to do that, though that's of secondary concern. That tool must use a file with the metainformation it needs (e.g., sound drivers are likely to get cascaded, and, thus, the higher level ones has the lower level ones as prereq). It is about this file we are talking about, not about how the kernel gets configured. We could _change_ the way the kernel gets configured (e.g., sysctl instead of compile-time) without changing this file, because the content remains the same: what options do I have? how are they related to each other? what the hell that option really mean? Going further, > 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. At _some_ point the syscon buffer must be configured. Like IRQ on my ISA ed0 must configured at some point. Like the choice between vt and syscon must be made at some point. Since these are all features of the "kernel", that's obviously the "kernel configuration". Though the process by which the kernel gets configured may (should) change, the user must still have control over all these options (well, most of them). How the kernel configurator will do it's work will change, but not the need for it. As a side point, > 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. The sysctl options and rc.conf may as well be included, at a later time, in the "kernel configurator". * You also said: > Your kernel configurator is /bin/ln, /bin/rm, and /bin/cp. [visions of Solaris' way of rc -- I hope you didn't think through on the above]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?83256570.003AE6C5.00>