Date: Wed, 17 Dec 1997 22:15:04 +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: <199712172215.PAA18891@usr07.primenet.com> In-Reply-To: <83256570.006A7EAF.00@papagaio.voga.com.br> from "daniel_sobral@voga.com.br" at Dec 17, 97 04:53:43 pm
next in thread | previous 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.
Run the install for it again. This time give it the "-d" option.
> - Recent bug fix in stable made a previously undetected bug appear in
> a driver, rendering the system unstable.
Run the install for the bugfix again. This time give it the "-d" option.
> - 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.
The driver/bugfix must be installed not at the time the hardware is
detected, but at an earlier time. What is your point? That install
and usage are disconnected? I'll give you that one for free.
> > I'm trying for POLA. POLA says "whatever you have in the machine, it
> > just works".
>
> Except when it doesn't.
I find something not working to be astonishing. That' doesn't fall
into what POLA says (I suppose I could argue this from the definition
of "*Least*" if you wanted to press me on it).
> 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?
I don't think that's a compelling argument, or most everyone would be
running UNIX instead of Windows on their desktop.
Something can be both easy and assinine, but just because something is
easy doesn't necessarily make it assinine. You can't tar an easy to
use UNIX system with athe Windows brush.
> > 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.
I fail to see how you can come up with a reasonable definition for
the ESC [ <x> m attributes, where <?> is 1, 2, 3, 4, 5, 6, or 7 when
you define the background/foreground away from the defaults, unless you
are constrained to define all other attribute pairs at the same time.
There's no other way to ensure the attribute pairs are unique from each
other, so that they may be distinguished by a user.
If you define background as black, and foreground as "high white" instead
of "low white" (defining the value for ESC [ 0 m), then what is pair
that comes frm ESC [ 5 m ("bold")?
You damage the ability to use standard ISO or even nonstandard SCO
color escape sequences when you define away from the defaults.
You can come up with all of the examples you want to where the user
chooses to consciously and intentionally violate POLA, and then point
at them and say "see! Your model violates POLA!".
As far as needing multiple screens of history buffer... sysctl it. Once.
It should stick and be that way forever after, if the system is working
like it should be.
> An option means that the computer can't read the mind of the people who is
> using it.
These are not things which should be configured at kernel build time.
Provide a user interface to sysctl, if you want to, such that you can
ensure consistency between attribute settings in syscons, and refuse to
save POLA-violating combinations, for your definition of POLA. I could
make the argument that not allowing the text to be set to black-on-black
violates POLA, for a user who is least astonished by a system that lets
them shoot themselves in the foot.
> > 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?
What applies to the programmer does not apply to the user, of course.
This is why it takes an engineer to do programming, and why it should
*not* take an enginneer to be a user.
> > 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.
Why fail to automate those options for which correct values can be
determined without a human?
Why set up exactly 4 BPF devices when the user might need 5? Why 4
when the user might need 0? Why not use a cloning device driver in a
devfs framework instead?
OK, now apply that to other devices. PTY's.
Do you need a WDC driver? I don't know... why don't you load one, then
load it and load the probe code an probe the wd0/wd1 devices, and if they
probe as not being there, unload the probe code and unload the WDC driver,
instead of having the user specify the thing in the config file?
Do you need NFS? I don't know... why don't you wait until the user asks
for an NFS mount before loading the code into the kernel?
Do you need a net card driver? I don't know, why don't you wait for
an IP address family or some other address family to need one before
loading the driver?
Do you need IP? I don't know, why don't you wait for TCP or UDP
sockets to be opened...
Etc..
Let me ask another question: what kernel configuration options do you
need? We can take them on a case-by-case basis and make them work
as tunables without the tuning needing to be done at compile time --
I'm sure of it.
> > > 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.
You are arguing my case for me. I am the one claiming you do not need to
have a configuration utility at kernel build time. If something can be
tuned at runtime, it should not be a build time option.
Once you get rid of all build time options, you are in my camp, that
no kernel configurator is necessary.
> 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."
Well, it will certainly not change in the near future if there is an
existing tuning mechanism that has to be replaced for the change to
be accepted. A kernel configurator that operates at compile time
*causes* sucky compile time options, it doesn't alleviate them.
> > > 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.
Does the manufacturer utility get the information right?
> > 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.
So? The current method is wrong. Death to the current method.
> So... I may presume that you do, indeed, see the need for "kernel
> configuration", as long as it is not called that? :-)
A set of kernel data that is persistent across boots and upgrades?
I see that. It's called a directory. It contains things like the
credentials information for the accounts needed to get the machine
at least to the point were it can contact other directory servers
for additional credentials information, at a minimum, or locally
maintain addition credential information.
Does this data include hardware configuration information? Not
for baseline functionaility, it doesn't. That information is in
the drivers, where it belongs, where the user can't do anything
to it to make it quit working.
> > 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.
What toes does it step on, other than "Not Invented Here"? Killing
homeless people steps on real toes, not religious authority that
exists without justification, other than the continuation of the
institutionalization of religious authority. The two are not
analogous.
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?199712172215.PAA18891>