Date: Wed, 17 Dec 1997 19:12:28 +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: <199712171912.MAA04021@usr02.primenet.com> In-Reply-To: <83256570.003AE6C5.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 17, 97 08:23:33 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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). You get to click "OK" or "Cancel" when it says "FreeBSD has detected new hardware; install drivers?". That's taking it to the ridiculous extreme, but the assumption that you'd want to remove drivers for existing hardware is just as ridiculous: why would you have installed them in the first place? I'm trying for POLA. POLA says "whatever you have in the machine, it just works". > 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? An option means the OS programmers have failed to abstract the need to explicitly select between alternatives. It's a failure of the machine to "do what I need". Note that even if we allow "do what I say", that still doesn't necessarily get the user "do what I need". I would go further, and say that it *probably* doesn't get the user "do what I need". Humans can only deal with a set of 5-9 items in a limited set (like the set of digits) at one time. This is why phone numbers are 7 digits, and why UI design guides stress a msmall number of items on a menu bar, and a small number of items on each submenu on the bar, and a small number of controls in the dialog selecting one of those items brings up, etc.. I view a 12k memory recovery as equivalent to Mac-dinking a document until all the pixels are in exactly "the right place". Either you will accept "close enough for 99%", or you will be one of those 1% remaining who understands the issues well enough actually go in with rm, ln, cp, mv, or whatever, and perform large diddles for questionable benefit, to their hearts content. > At _some_ point the syscon buffer must be configured. Yes. At the time the programmer puts a right-hand-side on: #define DEFAULT_SYSCONS_BUFFER_SIZE After that, it only needs to be diddled for people for whom the default was a bad choice. These people will post to -questions, and we will have a measure of how bad the choice was, and we can then change the right-hand-side value to optimize for the smallest number of questions. > Like IRQ on my ISA ed0 must configured at some point. This is to be done by the driver probe. The IRQ can only take on a limited subset of the available values. This limitation is device specific, and should be encoded in device specific data. If a new device comes out without the limitations, there needs to be a probe distinction so that the limitation difference can be objectively determined, and the device specific data should be changed. None of this requires a human at runtime, only at codetime. > Like the choice between vt and syscon must be made at some point. This is more fuzzy. These are equivalent drivers. I would argue that the preference should be expressed by installing or not installing the vt driver. This is an install script issue. This is persistent state that is maintained across rebuilds, since the existance of the driver object is easily detectable. > 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. If you want to call the MIB manager or the install tools a "kernel configurator", I'll call it a stretch, but I'll agree "yes, that's an acceptable mechanism, since it saves the user from having to make a choice without a full understanding of the consequences". You could argue that users should be educated, and then I'll argue by the same token that users should run FreeBSD instead of Microsoft OS's, but that there is a large gap between "should" and "do". > * 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] I did. I believe the Solaris rc.d mechanism is a better mechanism for allowing the installation of third party components which must be started at system startup, stopped at system shutdown, and reset by administrative fiat at the administrators whim. Tell me how to modularly add and remove a "postgres" package without it munging existing rc files, and without me munging the existing rc files so it doesn't have to, and you may be able to change my mind. Probably not, though, since IBCS2 ABI compatability (for which most commercial x86 UNIX software is written, like "Sybase", "Oracle", etc.) specifies an rc.d mechanism. 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?199712171912.MAA04021>