From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: Elmer Joandi <elmer@ylenurme.ee>
Cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>, linux-kernel@vger.kernel.org
Subject: Re: Universal debug macros.
Date: Mon, 27 Nov 2000 09:35:45 +0100 (MET) [thread overview]
Message-ID: <200011270835.JAA16502@cave.bitwizard.nl> (raw)
In-Reply-To: <Pine.LNX.4.10.10011270302570.24716-100000@yle-server.ylenurme.sise> from Elmer Joandi at "Nov 27, 2000 03:11:21 am"
Elmer Joandi wrote:
>
>
> On Mon, 27 Nov 2000, Rogier Wolff wrote:
>
> > Now, how is say "Red Hat" (*) going to ship kernels? Of course they are
> > going to turn off debugging. Then I'll be stuck with a non-recompiling
> > user-in-trouble with a non-debugging-enabled kernel.
>
> Red Hat will ship two kernels. Well, they actually ship now about 4 ones
> or something. So they will ship 8.
>
> Plus they will ship a script that recompiles kernel without user crawling
> in documentation.
It's not that Red Hat can't make a script that automatically recompiles
a certain package like the kernel. That's what a source-RPM actually IS.
People will want to upgrade to the latest kernel. People happen to
have deselected the compiler, or another essential tool for compiling
the kernel.
I've had LOTS of trouble myself when I wanted to upgrade a certain
machine which happened to be a '486 with 16M RAM intended as a
mail-router. So the machine had a minimal install: It started out with
a 170Mb disk. And you want 100Mb of mail-spool don't you. Well try and
cram a current distribution into 80M. That's kind of hard. So I had
agressively removed all packages I didn't need. Then suddenly there is
stuff that requires a kernel recompile (and it didn't want to work on
the system that I have for kernel-compiles), and you find out that if you
don't do the recommended install you miss quite a lot of packages that
are required for the kernel compile.
That's the kind of trouble that people end up running into. It took me
a while to figure it out. What do you expect from non-kernel hacking
random citizens?
The idea is, by the way, that you NEVER EVER want to run a kernel
without the double checks. Donald has a define at the top of his
drivers that defines the debug level, and I've never seen that at
"production". Similarly there are lots of "debugging" asserts in the
Linux kernel, that theoretically can go. Those need to stay to keep
Linux from crashing uncontrollably when things go slightly bad.
"Slightly bad" could be that a bit in memory falls over. "Slightly
bad" could be that a new bug in a driver is about to be found.
Andries calls this "globally correct". If your analysis of the kernel
finds that some assertion always holds, you could remove the check for
this pre-condition (the "assertions). Turns out that people will
prefer to run the "performance" kernel, and they will send in useless
bugreports like "my just hangs" much more often than now.
We'll end up in the current Windows situation where rebooting is
likely to help out. At first Linux will still be as stable as it is
now, but as soon as we start to lose half the useful bugreports to the
"sudden-hang"(*) monster, we'll quickly go downhill towards the
current state-of-affairs with MSWindows.
Roger.
(*) Or the "crashes spectacularly a few hours after the problem
actually accurred".
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-27 9:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-26 17:53 [PATCH] removal of "static foo = 0" Elmer Joandi
2000-11-26 18:36 ` Alexander Viro
2000-11-26 19:11 ` Elmer Joandi
2000-11-26 22:49 ` Rogier Wolff
2000-11-26 23:30 ` Universal debug macros Elmer Joandi
2000-11-27 0:45 ` Rogier Wolff
2000-11-27 1:11 ` Elmer Joandi
2000-11-27 4:25 ` H. Peter Anvin
2000-11-27 5:19 ` Michael Meissner
2000-11-27 16:56 ` Chmouel Boudjnah
2000-11-27 17:47 ` H. Peter Anvin
2000-11-27 17:56 ` Chmouel Boudjnah
2000-11-27 17:58 ` H. Peter Anvin
2000-11-27 18:10 ` Chmouel Boudjnah
2000-11-27 18:28 ` H. Peter Anvin
2000-11-27 18:39 ` Chmouel Boudjnah
2000-11-27 18:41 ` H. Peter Anvin
2000-11-27 21:09 ` Gerhard Mack
2000-11-27 8:35 ` Rogier Wolff [this message]
2000-11-27 14:42 ` Elmer Joandi
2000-11-27 14:59 ` Rogier Wolff
2000-11-27 15:58 ` Elmer Joandi
2000-11-28 1:34 ` Peter Samuelson
2000-11-27 16:37 ` Andrew E. Mileski
2000-11-27 17:01 ` Richard B. Johnson
2000-11-27 17:19 ` Andrew E. Mileski
2000-11-27 18:01 ` Richard B. Johnson
2000-11-27 19:55 ` Andrew E. Mileski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200011270835.JAA16502@cave.bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=elmer@ylenurme.ee \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox