On Tue, Oct 15, 2013 at 09:49:06AM -0700, Tony Luck wrote:
> On Tue, Oct 15, 2013 at 9:42 AM, Joe Perches wrote:
> > No guarantees are made about dmesg output.
>
> I'm with Joe here. Current users that parse dmesg have grumbled a bit
> that format changes - but they know that's the way life is.
On Tue, Oct 15, 2013 at 9:42 AM, Joe Perches wrote:
> No guarantees are made about dmesg output.
I'm with Joe here. Current users that parse dmesg have grumbled a bit
that format changes - but they know that's the way life is. Perhaps they'll
be too busy cheering about the TRACE formats that we
On Tue, 2013-10-15 at 14:29 +0200, Borislav Petkov wrote:
> Once we exposed it to userspace, we cannot simply assume
> that nothing is using it.
Yes, we can.
No guarantees are made about dmesg output.
If guarantees were made, no typo could ever be fixed
nor could any conversion from printk to de
On Tue, Oct 15, 2013 at 05:11:59PM +0530, Naveen N. Rao wrote:
> If so, how will disabling dmesg output and switching to a trace event
> help? The user-space program will still break unless they add support
> for that trace event, right?
Well, as yourself this: what happens to a userspace program
On 10/14/2013 10:42 PM, Tony Luck wrote:
On Mon, Oct 14, 2013 at 3:36 AM, Borislav Petkov wrote:
On Mon, Oct 14, 2013 at 12:55:00AM -0400, Chen Gong wrote:
Because most of data in CPER are empty or unimportant.
It is not about whether it is important or not - the question is whether
changing
On 10/14/2013 10:42 PM, Tony Luck wrote:
On Mon, Oct 14, 2013 at 3:36 AM, Borislav Petkov wrote:
On Mon, Oct 14, 2013 at 12:55:00AM -0400, Chen Gong wrote:
Because most of data in CPER are empty or unimportant.
It is not about whether it is important or not - the question is whether
changing
On Tue, Oct 15, 2013 at 05:18:35AM -0400, Chen Gong wrote:
> Looks fine to me. But a little bit out of current patch series. How
> about adding such interfaces after this patch series is merged?
Ok.
> And from your words, it looks like you prefer to reserve all current
> fields to avoid breaking
On Mon, Oct 14, 2013 at 11:50:47PM +0200, Borislav Petkov wrote:
> Date: Mon, 14 Oct 2013 23:50:47 +0200
> From: Borislav Petkov
> To: Tony Luck
> Cc: Chen Gong , Linux Kernel Mailing List
> , linux-acpi ,
> Lance Ortiz , "Naveen N. Rao"
>
> Subject: Re: [PA
On Mon, Oct 14, 2013 at 02:03:16PM -0700, Tony Luck wrote:
> Do you have a suggested mechanism for this disabling of dmesg?
Hmm, how about a 64-bit flag variable (we can use the remaining bits
for other stuff later) called x86_ras_flags which is private to
arch/x86/ras/core.c (a new file)...
[ b
On Mon, Oct 14, 2013 at 11:47 AM, Borislav Petkov wrote:
> It is basically the same idea as with the ras daemon - if we have a
> userspace consumer of ras trace events, we disable dmesg output. So the
> decision will be left to the userspace tool to disable dmesg output as a
> last step of its ini
On Mon, Oct 14, 2013 at 10:12:35AM -0700, Tony Luck wrote:
> This is an excellent idea - if the full data is being logged via
> TRACE, then we can drop to virtually nothing on the console (just have
> something similar to the "Machine check events logged" message so that
> people will get a tip tha
On Mon, Oct 14, 2013 at 3:36 AM, Borislav Petkov wrote:
> On Mon, Oct 14, 2013 at 12:55:00AM -0400, Chen Gong wrote:
>> Because most of data in CPER are empty or unimportant.
>
> It is not about whether it is important or not - the question is whether
> changing existing functionality which someon
On Mon, Oct 14, 2013 at 12:55:00AM -0400, Chen Gong wrote:
> Because most of data in CPER are empty or unimportant.
It is not about whether it is important or not - the question is whether
changing existing functionality which someone might rely upon is a
problem here? Someone might be expecting e
On Fri, Oct 11, 2013 at 06:02:08PM +0200, Borislav Petkov wrote:
> Date: Fri, 11 Oct 2013 18:02:08 +0200
> From: Borislav Petkov
> To: "Chen, Gong"
> Cc: tony.l...@intel.com, linux-kernel@vger.kernel.org,
> linux-a...@vger.kernel.org
> Subject: Re: [PATCH 7/8] AC
On Fri, Oct 11, 2013 at 02:32:45AM -0400, Chen, Gong wrote:
> Keep up only the most important fields for memory error
> reporting. The detail information will be moved to perf/trace
> interface.
>
> Suggested-by: Tony Luck
> Signed-off-by: Chen, Gong
> ---
> drivers/acpi/apei/cper.c | 42 ++
Keep up only the most important fields for memory error
reporting. The detail information will be moved to perf/trace
interface.
Suggested-by: Tony Luck
Signed-off-by: Chen, Gong
---
drivers/acpi/apei/cper.c | 42 ++
1 file changed, 14 insertions(+), 28 d
16 matches
Mail list logo
