public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 15:59:58 +0100 (MET)	[thread overview]
Message-ID: <200011271459.PAA18635@cave.bitwizard.nl> (raw)
In-Reply-To: <Pine.LNX.4.10.10011271630320.13242-100000@yle-server.ylenurme.sise> from Elmer Joandi at "Nov 27, 2000 04:42:13 pm"

Elmer Joandi wrote:
> 
> 
> On Mon, 27 Nov 2000, Rogier Wolff wrote:
> > 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.
> 
> But look at positive side:

I disagree:

> 1. really few people run development kernels despite the "performance" so 
> 	it probably will be with nondebug kernels.

Nope. If Red Hat gives a choice between a "performance" and a "with
debugging" kernel, everyone will chose "performance" under the
impression that thye won't be debugging their server.

> 2. production kernels get more solid

Nope. The kernels in production WILL NOT be more solid. They will
crash unexpectedly without any reference to what caused the crash.

> 3. because there could be a lot more debug points in development kernels

No. you state that they would come "at no cost" that would mean that
YOU are suggesting that you'd run a "performance" kernel, with (most)
of the debugging disabled.

Which means that you'd have disabled the debugging in MY part of the
kernel.

> 4. Distributors are interested in shipping debug-kernels.

Even if SuSE, Red Hat and Mandrake are convinced that shipping
debug-kernels is a good idea, then there is going to be some
distribution that has "ships performance kernels" as on of their
selling points. We'll then lose the bug-reports from that part of the
linux-users.

> You see the part that lots of asserts and debug prints  may go.
> I see the advantage, that  a lot of them can come, at no cost.

> Besides, if you want to have some assert anyway, then do not write
> it with system-wide macro but make your own or mark it as "included
> allways".  Faulty logic.

Well, your system-wide macro should have that option. But it will
be too easy to just disable it, and lose the debugging info. 

Sure if we'd convert to using your solution right now, we'd leave in
lots of those asserts and debugging prints "by default" exactly as
they are now. There possbily wouldn't even be a byte difference in the
binary. But in time, there will be many places where it is seen as
appropriate to put the test out-of-commission when marked as
"production" kernel.


		Roger. 

-- 
** 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/

  reply	other threads:[~2000-11-27 15:59 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
2000-11-27 14:42           ` Elmer Joandi
2000-11-27 14:59             ` Rogier Wolff [this message]
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=200011271459.PAA18635@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