From: Takenori Nagano <t-nagano@ah.jp.nec.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: k-miyoshi@cb.jp.nec.com, Bernhard Walle <bwalle@suse.de>,
kdb@oss.sgi.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, vgoyal@in.ibm.com,
"Eric W. Biederman" <ebiederm@xmission.com>,
Keith Owens <kaos@ocs.com.au>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/2] add new notifier function ,take2
Date: Thu, 25 Oct 2007 15:48:01 +0900 [thread overview]
Message-ID: <47203C21.2010505@ah.jp.nec.com> (raw)
In-Reply-To: <200710212200.04361.nickpiggin@yahoo.com.au>
Nick Piggin wrote:
>>> Is it possible to use a single bit of common code and a single
>>> notifier for these things? Or is it too difficult?
>> >
>> > I'm sorry, I can't understand your image well. I'd like to know details of
>> > your image.
>
> Rather than have each of "RAS tools" have their own notifier, and have
> the user specify the priority of the notifiers, introduce some layer
> which _knows_ that, for example, only one of these subsystems will be
> called (it could arbitrate, perhaps distinguish between destructive and
> non-destructive ones). It would need only a single notifier, but would
> then have a specific way of calling into the ras modules.
>
> Does this make sense? I guess it is a lot more work to do, so maybe your
> solution is the best one for now.
Hi Nick,
Thank you for your explanation. I understand. :-)
This is crash_stop (the common infrastructure for debug tools) by Keith Owens.
http://www.mail-archive.com/linux-arch@vger.kernel.org/msg01929.html
Is it same as your idea? I think it is very nice solution for debug tools
conflict problem.
By the way, on old notify_chain, if admin wants to change the list order, admin
have to recompile the kernel. My patches add new *generic* notify_chain which
admin can modify the list order. My patches are not only for RAS tools problem.
I'm happy if both patches are merged into mainline. :-)
Thanks,
Takenori
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Takenori Nagano <t-nagano@ah.jp.nec.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
vgoyal@in.ibm.com, linux-kernel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
k-miyoshi@cb.jp.nec.com, kexec@lists.infradead.org,
Bernhard Walle <bwalle@suse.de>, Keith Owens <kaos@ocs.com.au>,
kdb@oss.sgi.com
Subject: Re: [PATCH 0/2] add new notifier function ,take2
Date: Thu, 25 Oct 2007 15:48:01 +0900 [thread overview]
Message-ID: <47203C21.2010505@ah.jp.nec.com> (raw)
In-Reply-To: <200710212200.04361.nickpiggin@yahoo.com.au>
Nick Piggin wrote:
>>> Is it possible to use a single bit of common code and a single
>>> notifier for these things? Or is it too difficult?
>> >
>> > I'm sorry, I can't understand your image well. I'd like to know details of
>> > your image.
>
> Rather than have each of "RAS tools" have their own notifier, and have
> the user specify the priority of the notifiers, introduce some layer
> which _knows_ that, for example, only one of these subsystems will be
> called (it could arbitrate, perhaps distinguish between destructive and
> non-destructive ones). It would need only a single notifier, but would
> then have a specific way of calling into the ras modules.
>
> Does this make sense? I guess it is a lot more work to do, so maybe your
> solution is the best one for now.
Hi Nick,
Thank you for your explanation. I understand. :-)
This is crash_stop (the common infrastructure for debug tools) by Keith Owens.
http://www.mail-archive.com/linux-arch@vger.kernel.org/msg01929.html
Is it same as your idea? I think it is very nice solution for debug tools
conflict problem.
By the way, on old notify_chain, if admin wants to change the list order, admin
have to recompile the kernel. My patches add new *generic* notify_chain which
admin can modify the list order. My patches are not only for RAS tools problem.
I'm happy if both patches are merged into mainline. :-)
Thanks,
Takenori
next prev parent reply other threads:[~2007-10-25 6:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-18 6:45 [PATCH 0/2] add new notifier function ,take2 Takenori Nagano
2007-10-18 6:45 ` Takenori Nagano
2007-10-18 7:06 ` Andrew Morton
2007-10-18 7:06 ` Andrew Morton
2007-10-18 8:06 ` Vivek Goyal
2007-10-18 8:06 ` Vivek Goyal
2007-10-18 8:52 ` Takenori Nagano
2007-10-18 8:52 ` Takenori Nagano
2007-10-21 12:00 ` Nick Piggin
2007-10-21 12:00 ` Nick Piggin
[not found] ` <471D4668.4090300@ah.jp.nec.com>
2007-10-24 6:48 ` sysfs sys/kernel/ namespace (was Re: [PATCH 0/2] add new notifier function ,take2) Nick Piggin
2007-10-24 11:12 ` Kay Sievers
2007-10-25 2:31 ` Nick Piggin
2007-10-25 5:45 ` Greg KH
2007-10-25 6:12 ` Nick Piggin
2007-10-25 6:48 ` Takenori Nagano [this message]
2007-10-25 6:48 ` [PATCH 0/2] add new notifier function ,take2 Takenori Nagano
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=47203C21.2010505@ah.jp.nec.com \
--to=t-nagano@ah.jp.nec.com \
--cc=akpm@linux-foundation.org \
--cc=bwalle@suse.de \
--cc=ebiederm@xmission.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=vgoyal@in.ibm.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 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.