From: ebiederm@xmission.com (Eric W. Biederman)
To: Takenori Nagano <t-nagano@ah.jp.nec.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
kdb@oss.sgi.com, vgoyal@redhat.com, kexec@lists.infradead.org,
Keith Owens <kaos@ocs.com.au>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Randy Dunlap <rdunlap@xenotime.net>,
greg@kroah.com, bwalle@suse.de, k-miyoshi@cb.jp.nec.com
Subject: Re: [PATCH 0/3] add new notifier function ,take4
Date: Wed, 23 Apr 2008 05:48:53 -0700 [thread overview]
Message-ID: <m1wsmoohxm.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <480F1957.2070609@ah.jp.nec.com> (Takenori Nagano's message of "Wed, 23 Apr 2008 20:11:19 +0900")
Takenori Nagano <t-nagano@ah.jp.nec.com> writes:
> Hi,
>
> changelog take3 -> take4
>
> - Rebased 2.6.25-mm1
> - Add a document
> - Add kdump on panic_notifier
>
> These patches add new notifier function and implement it to panic_notifier_list.
> We used the hardcoded notifier chain so far, but it was not flexible. New
> notifier is very flexible, because user can change a list of order by control
> files.
>
> And, third patch moves crash_kexec() to panic_notifier. It helps us to do
> something before taking a crash dump. It's useful for some RAS tools developer.
> If you want to use it, you have to set config option DUMP_ON_PANIC_NOTIFIER to
> Y. Default value of DUMP_ON_PANIC_NOTIFIER is N.
> If you set DUMP_ON_PANIC_NOTIFIER to N, kdump has no difference before.
NAK.
Reasonable alternatives have been suggested. No rebuttal has been given.
Just buggy patches with insufficient description of what you are doing
and why.
I am tired of seeing the same patch come up again and again without even
all of the easy problems that are pointed out addressed, much less the
design issues considered or addressed.
I see no evidence that we need this mechanism to achieve any of
the goals proposed.
This mechanism drastically reduces the maintainability of the
kexec on panic code as it makes the code path indiscoverable
and thus unreviewable.
This mechanism gives an unnecessary and confusing policy control
to users when we should be able to auto-tune based on the situation.
CONFIGURABILITY IS BAD in this context.
I think this entire approach is a BAD IDEA. Please go back to
the drawing board. Please describe the specific problems you
are trying to solve and why the existing mechanisms can not be
made to work and we can work with you.
Eric
prev parent reply other threads:[~2008-04-23 12:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-23 11:11 [PATCH 0/3] add new notifier function ,take4 Takenori Nagano
2008-04-23 12:32 ` Vivek Goyal
2008-04-23 12:48 ` Eric W. Biederman [this message]
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=m1wsmoohxm.fsf@frodo.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=bwalle@suse.de \
--cc=greg@kroah.com \
--cc=k-miyoshi@cb.jp.nec.com \
--cc=kaos@ocs.com.au \
--cc=kdb@oss.sgi.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=rdunlap@xenotime.net \
--cc=t-nagano@ah.jp.nec.com \
--cc=vgoyal@redhat.com \
/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