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
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
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
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
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
-a...@vger.kernel.org,
Lance Ortiz lance.or...@hp.com, Naveen N. Rao
naveen.n@linux.vnet.ibm.com
Subject: Re: [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output
format
User-Agent: Mutt/1.5.21 (2010-09-15)
On Mon, Oct 14, 2013 at 02:03:16PM -0700, Tony Luck wrote:
Do you have
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 10/14/2013 10:42 PM, Tony Luck wrote:
On Mon, Oct 14, 2013 at 3:36 AM, Borislav Petkov b...@alien8.de 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
On 10/14/2013 10:42 PM, Tony Luck wrote:
On Mon, Oct 14, 2013 at 3:36 AM, Borislav Petkov b...@alien8.de 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
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 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
On Tue, Oct 15, 2013 at 9:42 AM, Joe Perches j...@perches.com 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
On Tue, Oct 15, 2013 at 09:49:06AM -0700, Tony Luck wrote:
On Tue, Oct 15, 2013 at 9:42 AM, Joe Perches j...@perches.com 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
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)...
[
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
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
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
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
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
On Mon, Oct 14, 2013 at 3:36 AM, Borislav Petkov b...@alien8.de 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
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 that
On Mon, Oct 14, 2013 at 11:47 AM, Borislav Petkov b...@alien8.de 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
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)...
[
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
] ACPI, APEI, CPER: Cleanup CPER memory error output
format
User-Agent: Mutt/1.5.21 (2010-09-15)
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
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
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 tony.l...@intel.com
Signed-off-by: Chen, Gong gong.c...@linux.intel.com
---
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 tony.l...@intel.com
Signed-off-by: Chen, Gong gong.c...@linux.intel.com
---
drivers/acpi/apei/cper.c | 42
32 matches
Mail list logo
