Date: Wed, 17 Dec 1997 16:53:43 -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.006A7EAF.00@papagaio.voga.com.br>
next in thread | raw e-mail | index | archive | help
> 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?
Easy. Bugs. Eg.:
- Driver being developed in current incorrectly identifies my card as
being of the same model, causing all sorts of problem.
- Recent bug fix in stable made a previously undetected bug appear in
a driver, rendering the system unstable.
- Fill in your example of Bug Horror Story.
Notice that, in both case, the configuration must be made not at the time
the hardware is detected, but at a later time.
> I'm trying for POLA. POLA says "whatever you have in the machine, it
> just works".
Except when it doesn't.
I'm trying for: yeah, ok, you do know a lot about what you are doing, but
you do not know what *I* am doing, so let me do what *I* want to do. Let me
shoot myself in the foot. Otherwise, why use Unix instead of Windows (et
cetera) at all?
> 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".
It let's the end-user avoid short sightedness such as shown above. For
instance, I fail to see how the system my decide that I "need" a blue
background, or that I don't "need" more than a single screen worth of
history buffer.
An option means that the computer can't read the mind of the people who is
using it.
> 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..
So? I suppose a programmer shouldn't code programs of more than nine lines
worth of code because of that? Or what applies to the system manager does
not apply to the programmer? And the same things goes between end user and
the two above?
> 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.
Of course, as far as RL goes, there are many people out there who belongs
to the former group but have a job requiring the skills of the later. We
have two choices: we ignore them or we don't.
Besides, computers are used to automate jobs. Why automate so many tasks,
and then fail to automate this single task because people who do it should
know how to do it by hand? Well, I know how to write with pen and paper,
but I still prefer to use a word processor if the job is large enough.
> > 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.
Recompile the kernel to change the buffer size???????????? That should be
possible to do at run-time, without stopping the machine at all.
Besides, compile time options suck. IMHO, but that's an O not likely to
change in the near future. And certainly not with an argument such as
"well, you know how to do it the hard way, so that's the way you should
pick."
> > Like IRQ on my ISA ed0 must configured at some point.
> This is to be done by the driver probe.
Well, I have yet to see any OS correctly identify how my ed0 is configured.
I have been taking that as an indication that it is simply not possible.
> 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.
Well, the current method of selecting between vt and syscon is the one
above. It is being done through a file that is run through a program called
"config". This file should be edited by hand, something that fashion many
people, but many more would like an easier interface. The development of an
easier interface is the topic of this thread.
So... I may presume that you do, indeed, see the need for "kernel
configuration", as long as it is not called that? :-)
> 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.
Well, I consider the Solaris rc.d mechanism akin to killing all the
homeless people in the world to solve their problem. It kind of works, but
it is not acceptable.
--
Daniel C. Sobral (8-DCS)
Daniel_Sobral@voga.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?83256570.006A7EAF.00>