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 <bp@xxxxxxxxx> > To: Tony Luck <tony.luck@xxxxxxxxx> > Cc: Chen Gong <gong.chen@xxxxxxxxxxxxxxx>, Linux Kernel Mailing List > <linux-kernel@xxxxxxxxxxxxxxx>, linux-acpi <linux-acpi@xxxxxxxxxxxxxxx>, > Lance Ortiz <lance.ortiz@xxxxxx>, "Naveen N. Rao" > <naveen.n.rao@xxxxxxxxxxxxxxxxxx> > 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 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)... > > [ btw, I'm thinking of something similar to efi's x86_efi_facility which we > nicely query with test_bit and set with set_bit and clear_bit, etc, etc ] > > Also, look at arch/x86/platform/efi/efi.c::efi_enabled() how it hides > the actual variable and we can do something similar so that eMCA and > other users like cper.c can do > > apei_estatus_print_section: > > if (!ras_tracepoint_enabled()) > cper_print_mem(...) > > We set the bit in x86_ras_flags from, say, debugfs, i.e., a userspace > tool sets it and from that moment on all RAS output is rerouted to the > trace event. I.e., the output for which there is a trace event... > > How does that look like? > Looks fine to me. But a little bit out of current patch series. How about adding such interfaces after this patch series is merged? And from your words, it looks like you prefer to reserve all current fields to avoid breaking user space things. IOW, drop patch [7/8] and use another patch with above idea to get the same purpose. This is what you want, Boris?
Attachment:
signature.asc
Description: Digital signature
