From: Ingo Molnar <mingo@elte.hu>
To: Alain Knaff <alain@knaff.lu>
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 11:37:27 +0100 [thread overview]
Message-ID: <20090114103727.GA2913@elte.hu> (raw)
In-Reply-To: <496DA0FF.2060206@knaff.lu>
* Alain Knaff <alain@knaff.lu> wrote:
> Ingo Molnar wrote:
> > * Alain Knaff <alain@knaff.lu> wrote:
> >
> >> 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... [...]
> >
> > By your argument the ton of warnings we emit in various situations are
> > wrong too and all should be panic()s.
>
> That is not my argument. I never said something like that.
I did not say that it is your argument, i said it is _by_ your argument:
i.e. it is a logical extension of your argument.
Exactly how is such a warning different from other warnings that the
kernel already emits? For which people supposedly have to set up a serial
console? (which they dont have to)
Answer: it is not different, and it is exactly as hard or easy to find as
the other ones. I.e. why should this warning get a special treatment? I
already told the kernel that i dont want a gzip ramfs image decompressor
by turning off the (otherwise default-enabled) option. panic()ing on that
decision, overriding my decision and escallating it into a non-working
system is silly and a bug.
Ingo
next prev parent reply other threads:[~2009-01-14 10:37 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
2009-01-14 7:48 ` Ingo Molnar
2009-01-14 8:23 ` Alain Knaff
2009-01-14 10:37 ` Ingo Molnar [this message]
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=20090114103727.GA2913@elte.hu \
--to=mingo@elte.hu \
--cc=alain@knaff.lu \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--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.