All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alain Knaff <alain@knaff.lu>
To: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Al Viro <viro@ftp.linux.org.uk>
Subject: Re: The policy on initramfs decompression failure
Date: Wed, 14 Jan 2009 08:02:37 +0100	[thread overview]
Message-ID: <496D8E0D.5090401@knaff.lu> (raw)
In-Reply-To: <20090114054022.GA11153@elte.hu>

Ingo Molnar wrote:
> And your argument makes little sense: if there is something wrong then one 
> looks at the logs _anyway_.

Unfortunately, not everybody has the knowledge or equipment ready to set
up a serial console... And logs in the classical sense (in a logfile...)
don't exist yet at that early stage of boot, because it happens _before_
the kernel is able to write to the filesystem...

> Are you suggesting that all warnings that 
> signal some potential badness should result in a panic? That is 
> nonsensical.

There must be some misunderstanding somewhere. I didn't make any such
suggestion. I agree with you, such a suggestion would be nonsensical.

> What you seem to be arguing for is to introduce a kernel option that says 
> "panic on warnings" - so that folks cannot miss warnings. _That_ would be 
> a fair argument.

That would be an interesting idea, but might lead to the opposite
problem (kernel stopping _before_ the real problem happens).

Maybe what we could do is "fix" panic() such that it doesn't disable
Shift-Pgup. But I admit that such a change may not be trivial to
implement, as there may be cases where the interrupt system is fubar,
and all interrupt handlers (including keyboard) would need to be disabled.

> Panics are rarely good, unless the user asks for it, period. We've been 
> flipping over BUG_ON()s to WARN_ON() everywhere where it matters in 
> practice.
> 
> 	Ingo

That is a valid philosophical discussion. But shouldn't we move it to a
thread of its own?

Regards,

Alain

  reply	other threads:[~2009-01-14  7:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-13 22:38 The policy on initramfs decompression failure H. Peter Anvin
2009-01-13 23:17 ` Alain Knaff
2009-01-14  5:40   ` Ingo Molnar
2009-01-14  7:02     ` Alain Knaff [this message]
2009-01-14  7:48       ` Ingo Molnar
2009-01-14  8:23         ` Alain Knaff
2009-01-14 10:37           ` Ingo Molnar
2009-01-14 17:42         ` H. Peter Anvin
2009-01-14  1:18 ` Theodore Tso
2009-01-14  6:51   ` Alain Knaff
     [not found] <bU0fj-7Ap-43@gated-at.bofh.it>
2009-01-13 23:42 ` Bodo Eggert
2009-01-14  5:45   ` Ingo Molnar
2009-01-14  6:47     ` Alain Knaff
2009-01-14  7:45       ` Ingo Molnar
2009-01-14 15:19     ` Bodo Eggert
     [not found] ` <bU0If-8vA-19@gated-at.bofh.it>
     [not found]   ` <bU6NE-1bi-3@gated-at.bofh.it>
     [not found]     ` <bU837-3lq-11@gated-at.bofh.it>
     [not found]       ` <bU8FR-4by-23@gated-at.bofh.it>
     [not found]         ` <bU9iw-5gV-1@gated-at.bofh.it>
     [not found]           ` <bUbkj-8un-5@gated-at.bofh.it>
2009-01-14 18:35             ` Bodo Eggert
     [not found]         ` <bUi2r-2kd-13@gated-at.bofh.it>
2009-01-18 12:55           ` Bodo Eggert

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=496D8E0D.5090401@knaff.lu \
    --to=alain@knaff.lu \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=viro@ftp.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.