[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20101109145540.BC72.A69D9226@jp.fujitsu.com>
Date: Tue, 9 Nov 2010 14:54:52 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc: kosaki.motohiro@...fujitsu.com, Mike Waychison <mikew@...gle.com>,
simon.kagstrom@...insight.net, davem@...emloft.net,
nhorman@...driver.com, Matt Mackall <mpm@...enic.com>,
adurbin@...gle.com, linux-kernel@...r.kernel.org,
chavey@...gle.com, Greg KH <greg@...ah.com>,
Americo Wang <xiyou.wangcong@...il.com>,
akpm@...ux-foundation.org, linux-api@...r.kernel.org
Subject: Re: [PATCH v2 17/23] kmsg_dumper: Introduce a new 'SOFT' dump reason
> Hi
>
> > It is a useful to be able to exercise kmsg_dumper implementations without
> > requiring a kernel oops or panic. This commit adds a new reason called
> > KMSG_DUMP_SOFT, which signifies that the system isn't really going down.
> >
> > This logic is used in a later commit that introduces the netoops driver.
> >
> > Signed-off-by: Mike Waychison <mikew@...gle.com>
> > ---
> >
> > It is also possible that we not introduce KMSG_DUMP_SOFT, and simply overload
> > the existing KMSG_DUMP_OOPS reason, but I figured that this would be cleaner.
> >
> > TODO: Make sure mtdoops and ramoops do something useful with this flag?
>
> Yes. If userland explicitly want to log, we have no reason to refuse it. :)
I meant I think your change has no problem.
> But, I don't think KMSG_DUMP_SOFT is good name because _SOFT don't explain
> anything.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists