From: Josef Sipek <jsipek@fsl.cs.sunysb.edu>
To: Pavel Machek <pavel@ucw.cz>
Cc: Dave Jones <davej@redhat.com>,
David Lang <dlang@digitalinsight.com>,
Jan Engelhardt <jengelh@linux01.gwdg.de>,
Bernd Eckenfels <be-news06@lina.inka.de>,
linux-kernel@vger.kernel.org
Subject: Re: oops pauser. / boot_delayer
Date: Sun, 8 Jan 2006 18:39:35 -0500 [thread overview]
Message-ID: <20060108233935.GA12745@filer.fsl.cs.sunysb.edu> (raw)
In-Reply-To: <20060108230827.GB1686@elf.ucw.cz>
On Mon, Jan 09, 2006 at 12:08:27AM +0100, Pavel Machek wrote:
> On Ne 08-01-06 14:30:00, Josef Sipek wrote:
> > On Sun, Jan 08, 2006 at 02:21:32PM +0100, Pavel Machek wrote:
> > > On Pá 06-01-06 00:36:09, Dave Jones wrote:
> > > > So disable CONFIG_CRYPTO_TEST. There's no reason to test this stuff every boot.
> > >
> > > Maybe even with CRYPTO_TEST enabled we could only report _failures_?
> >
> > Why? As far as I know, it is intended for developers as a regression test. I say
> > if you don't like the output, make the thing a module or don't compile it at all.
>
> I don't like the output, but if it only reported failures, I could
> leave it running and potentially catch some strange failures.
I agree that it is useful to know about strange failures, however I still maintain
that _if_ the module is intended as a regression test for developers, than the
excessive (?) output is fair. I think that the most logical course of action is to
have a verbosity module paramter which defaults to displaying errors only, but it still
allows developers to get all the information they need.
> Is reporting successes actually useful?
Then I propose: :)
diff -r b4fca0ece97f kernel/sys.c
--- a/kernel/sys.c Sat Oct 22 19:24:10 2005 +0300
+++ b/kernel/sys.c Sun Jan 8 18:26:49 2006 -0500
@@ -436,7 +436,6 @@
void kernel_halt(void)
{
kernel_halt_prepare();
- printk(KERN_EMERG "System halted.\n");
machine_halt();
}
EXPORT_SYMBOL_GPL(kernel_halt);
Jeff.
next prev parent reply other threads:[~2006-01-08 23:39 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-05 4:52 oops pauser Dave Jones
2006-01-05 6:10 ` oops pauser. / boot_delayer Randy.Dunlap
2006-01-05 7:30 ` Bernd Eckenfels
2006-01-05 8:07 ` Jan Engelhardt
2006-01-06 1:28 ` David Lang
2006-01-06 5:36 ` Dave Jones
2006-01-06 7:00 ` David Lang
2006-01-08 13:21 ` Pavel Machek
2006-01-08 19:30 ` Josef Sipek
2006-01-08 23:08 ` Pavel Machek
2006-01-08 23:39 ` Josef Sipek [this message]
2006-01-06 7:36 ` Jan Engelhardt
2006-01-06 8:33 ` David Lang
2006-01-05 9:25 ` Grant Coady
2006-01-05 15:31 ` Mark Lord
2006-01-05 15:38 ` Avishay Traeger
2006-01-05 19:15 ` Mark Lord
2006-01-05 11:11 ` Dave Jones
2006-01-07 21:44 ` Kurtis D. Rader
2006-01-07 21:48 ` Arjan van de Ven
2006-01-07 22:00 ` Kurtis D. Rader
2006-01-08 23:29 ` David Lang
2006-01-07 22:27 ` Bernd Eckenfels
2006-01-05 8:15 ` oops pauser Jan Engelhardt
2006-01-05 10:33 ` Dave Jones
2006-01-05 11:05 ` Jan Engelhardt
2006-01-05 12:05 ` Keith Owens
2006-01-05 15:17 ` Jesper Juhl
2006-01-05 13:46 ` Kurt Wall
2006-01-06 1:24 ` David Lang
2006-01-06 1:41 ` Josef Sipek
2006-01-08 13:38 ` Ville Herva
2006-01-08 13:53 ` Randy.Dunlap
2006-01-08 19:35 ` Jan Engelhardt
2006-01-09 1:43 ` Randy.Dunlap
2006-01-08 19:40 ` Grant Coady
2006-01-09 1:45 ` Randy.Dunlap
2006-01-09 16:15 ` Jan Engelhardt
2006-01-09 16:25 ` Ville Herva
2006-01-09 16:39 ` Randy.Dunlap
2006-01-05 13:37 ` Alan Cox
2006-01-05 20:52 ` Dave Jones
2006-01-06 13:31 ` Alan Cox
2006-01-06 20:33 ` Dave Jones
2006-01-06 15:22 ` Pavel Machek
2006-01-06 19:06 ` Jan Engelhardt
2006-01-06 22:34 ` Pavel Machek
2006-01-06 22:48 ` Dave Jones
2006-01-05 13:58 ` Avishay Traeger
2006-01-05 20:54 ` Dave Jones
2006-01-06 0:19 ` Josef Sipek
2006-01-06 1:12 ` Bernd Eckenfels
2006-01-06 1:35 ` Josef Sipek
2006-01-06 2:21 ` Bernd Eckenfels
2006-01-05 14:39 ` Kyle McMartin
2006-01-09 18:43 ` Console debugging wishlist was: " Andi Kleen
2006-01-10 20:25 ` Jan Engelhardt
2006-01-10 20:29 ` Josef Sipek
2006-01-10 20:44 ` Jan Engelhardt
2006-01-10 22:54 ` Josef Sipek
2006-01-10 20:46 ` Andi Kleen
2006-01-10 20:45 ` Andi Kleen
2006-01-10 21:06 ` Jan Engelhardt
2006-01-10 21:18 ` Andi Kleen
2006-01-10 21:30 ` Jan Engelhardt
2006-01-11 12:24 ` Antonino A. Daplas
2006-01-11 12:31 ` Andi Kleen
2006-01-11 13:05 ` Antonino A. Daplas
2006-01-11 13:17 ` Andi Kleen
2006-01-11 13:43 ` Antonino A. Daplas
2006-01-11 13:51 ` Andi Kleen
2006-01-11 18:34 ` Jan Engelhardt
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=20060108233935.GA12745@filer.fsl.cs.sunysb.edu \
--to=jsipek@fsl.cs.sunysb.edu \
--cc=be-news06@lina.inka.de \
--cc=davej@redhat.com \
--cc=dlang@digitalinsight.com \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/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
all inboxes | Powered by JetHome®