Re: [PATCH, RFC] panic-note: Annotation from user space for panics

2009-11-12 Thread Marco Stornelli
Sincerely, I don't understand why we should involve the kernel to gather
this kind of information when we can use other (user-space) tools, only
to have all in a single report maybe? I think it's a bit weak reason
to include this additional behavior in the kernel.

David VomLehn ha scritto:
 Allows annotation of panics to include platform information. It's no big
 deal to collect information, but way helpful when you are collecting
 failure reports from a eventual base of millions of systems deployed in
 other people's homes.
 

Marco
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH, RFC] panic-note: Annotation from user space for panics

2009-11-12 Thread Matt Mackall
On Wed, 2009-11-11 at 21:13 -0500, David VomLehn wrote:
 Allows annotation of panics to include platform information. It's no big
 deal to collect information, but way helpful when you are collecting
 failure reports from a eventual base of millions of systems deployed in
 other people's homes.

I'd like to hear a bit more use case motivation on this feature. Also,
why do you want more than a page?

-- 
http://selenic.com : development and support for Mercurial and Linux


--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH, RFC] panic-note: Annotation from user space for panics

2009-11-12 Thread Paul Gortmaker

David VomLehn wrote:

Allows annotation of panics to include platform information. It's no big
deal to collect information, but way helpful when you are collecting
failure reports from a eventual base of millions of systems deployed in
other people's homes.

One of the biggest reasons this is an RFC is that I'm uncomfortable with
putting the pseudo-file that holds the annotation information in /proc.
Different layers of the software stack may drop dynamic information, such
as DHCP-supplied IP addresses, in here as they come up. This means it's
necessary to be able to append to the end of the annotation, so this looks
much more like a real file than a sysctl file.  It also has multiple lines,
which doesn't look a sysctl file. Annotation can be viewed as a debug thing,
so maybe it belongs in debugfs, but people seem to be doing somewhat different
things with that filesystem.

So, suggestions on this issue, and any others are most welcome. If there a
better way to do this, I'll be happy to use it.

Signed-off-by: David VomLehn dvoml...@cisco.com
---



--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -70,6 +70,7 @@ NORET_TYPE void panic(const char * fmt, ...)
vsnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
printk(KERN_EMERG Kernel panic - not syncing: %s\n,buf);
+   panic_note_print();
 #ifdef CONFIG_DEBUG_BUGVERBOSE
dump_stack();
 #endif



Why hook into panic() directly like this, vs. using the panic
notifier list? If you use that, and then put the data handling
magic that you need into your own kernel module that knows how
to interface with the reporting apps that you have, you can
do the whole thing without having to alter existing code, I think.

Paul.


diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 30df586..bade7a1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1045,6 +1045,14 @@ config DMA_API_DEBUG
  This option causes a performance degredation.  Use only if you want
  to debug device drivers. If unsure, say N.
 
+config PANIC_NOTE

+   bool Create file for user space data to be reported at panic time
+   default n
+   help
+ This creates a pseudo-file, named /proc/panic_note, into which
+ user space data can be written. If a panic occurs, the contents
+ of the file will be included in the failure report.
+
 source samples/Kconfig
 
 source lib/Kconfig.kgdb


--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH, RFC] panic-note: Annotation from user space for panics

2009-11-12 Thread David VomLehn
On Thu, Nov 12, 2009 at 01:06:51PM -0500, Matt Mackall wrote:
 On Wed, 2009-11-11 at 21:13 -0500, David VomLehn wrote:
  Allows annotation of panics to include platform information. It's no big
  deal to collect information, but way helpful when you are collecting
  failure reports from a eventual base of millions of systems deployed in
  other people's homes.
 
 I'd like to hear a bit more use case motivation on this feature. Also,
 why do you want more than a page?

Hopefully, I have addressed the first question in my previous email. As
for the second, I doubt there is a need for more than a page. I just picked
a value to start developing with. This is still a work in progress...

 http://selenic.com : development and support for Mercurial and Linux

David VL
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH, RFC] panic-note: Annotation from user space for panics

2009-11-12 Thread David VomLehn
On Thu, Nov 12, 2009 at 02:50:41PM -0500, Paul Gortmaker wrote:
 David VomLehn wrote:
 Allows annotation of panics to include platform information. It's no big
 deal to collect information, but way helpful when you are collecting
 failure reports from a eventual base of millions of systems deployed in
 other people's homes.
...
 Why hook into panic() directly like this, vs. using the panic
 notifier list? If you use that, and then put the data handling
 magic that you need into your own kernel module that knows how
 to interface with the reporting apps that you have, you can
 do the whole thing without having to alter existing code, I think.

I agree--a panic notifier list is probably a better approach.

David VL
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html