Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/28/07, Rob Landley <[EMAIL PROTECTED]> wrote: > On Friday 28 September 2007 7:11:03 am Vegard Nossum wrote: > > wrong. We can, however, use KBUILD_MODNAME as a default value for > > KPRINT_DRIVER, like: > > static const char *KPRINT_DRIVER = KBUILD_MODNAME; > > which would pre-process to

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Rob Landley
On Friday 28 September 2007 7:11:03 am Vegard Nossum wrote: > wrong. We can, however, use KBUILD_MODNAME as a default value for > KPRINT_DRIVER, like: > static const char *KPRINT_DRIVER = KBUILD_MODNAME; > which would pre-process to something like: > static const char *KPRINT_DRIVER = "bcm43xx";

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Miguel Ojeda
On 9/28/07, Vegard Nossum <[EMAIL PROTECTED]> wrote: > On 9/28/07, Miguel Ojeda <[EMAIL PROTECTED]> wrote: > > On 9/28/07, Vegard Nossum <[EMAIL PROTECTED]> wrote: > > > reason we can't use KBUILD_MODNAME is that this is defined on the > > > command line. The declaration inside the header would

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/28/07, Miguel Ojeda <[EMAIL PROTECTED]> wrote: > On 9/28/07, Vegard Nossum <[EMAIL PROTECTED]> wrote: > > reason we can't use KBUILD_MODNAME is that this is defined on the > > command line. The declaration inside the header would thus be horribly > > wrong. We can, however, use KBUILD_MODNAME

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Miguel Ojeda
On 9/28/07, Vegard Nossum <[EMAIL PROTECTED]> wrote: > On 9/27/07, Vegard Nossum <[EMAIL PROTECTED]> wrote: > > * Use SUBSYSTEM and KBUILD_MODNAME > > snip. > > > 2.1.5. Subsystem/driver tags > > > > Many parts of the kernel already prefix their log messages with a > > subsystem and/or driver

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/27/07, Vegard Nossum <[EMAIL PROTECTED]> wrote: > * Use SUBSYSTEM and KBUILD_MODNAME snip. > 2.1.5. Subsystem/driver tags > > Many parts of the kernel already prefix their log messages with a > subsystem and/or driver tag to identify the source of a particular > message. With the kprint

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/28/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Sep 27 2007 23:18, Vegard Nossum wrote: > > * kprint_() is better than kprint( >case of the default log-level, the argument can be omitted. > > * Memory allocated for entries and arguments is done in a ring-buffer > >with

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/28/07, Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Sep 28, 2007, at 03:31:11, Geert Uytterhoeven wrote: > > Can't you store the loglevel in the kprint_block and check it in > > all successive kprint_*() macros? If gcc knows it's constant, it > > can optimize the non-wanted code away. As

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
> If-blocks spanning macros are really dangerous! > > E.g. an Ethernet driver may want to do: > > kprint_block(, "MAC "); > for (i = 0; i < 6; i++) { > card->mac[i] = obtain_mac_byte_from_hw(i); > kprint_block(, "%02x", card->mac[i]); > } > >

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Jan Engelhardt
On Sep 27 2007 23:18, Vegard Nossum wrote: > * kprint_() is better than kprint(case of the default log-level, the argument can be omitted. > * Memory allocated for entries and arguments is done in a ring-buffer >with variable-sized chunks. Arguments are chained with a singly- >

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Dick Streefland
"Vegard Nossum" <[EMAIL PROTECTED]> wrote: | It should be possible to optimize out multi-line (block) entries | based on log-level filtering even though the log-level is only given | in the first call (the initializer). It may take the shape of an | if-block that spans several macros. This is

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Kyle Moffett
On Sep 28, 2007, at 03:31:11, Geert Uytterhoeven wrote: Can't you store the loglevel in the kprint_block and check it in all successive kprint_*() macros? If gcc knows it's constant, it can optimize the non-wanted code away. As other fields in struct kprint_block cannot be constant (they

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Geert Uytterhoeven
On Thu, 27 Sep 2007, Vegard Nossum wrote: > It should be possible to optimize out multi-line (block) entries > based on log-level filtering even though the log-level is only given > in the first call (the initializer). It may take the shape of an > if-block that spans several macros. This is not

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Geert Uytterhoeven
On Thu, 27 Sep 2007, Vegard Nossum wrote: It should be possible to optimize out multi-line (block) entries based on log-level filtering even though the log-level is only given in the first call (the initializer). It may take the shape of an if-block that spans several macros. This is not

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Kyle Moffett
On Sep 28, 2007, at 03:31:11, Geert Uytterhoeven wrote: Can't you store the loglevel in the kprint_block and check it in all successive kprint_*() macros? If gcc knows it's constant, it can optimize the non-wanted code away. As other fields in struct kprint_block cannot be constant (they

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/28/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On Sep 27 2007 23:18, Vegard Nossum wrote: * kprint_level() is better than kprint(level), ) because in the case of the default log-level, the argument can be omitted. * Memory allocated for entries and arguments is done in a

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/28/07, Miguel Ojeda [EMAIL PROTECTED] wrote: On 9/28/07, Vegard Nossum [EMAIL PROTECTED] wrote: reason we can't use KBUILD_MODNAME is that this is defined on the command line. The declaration inside the header would thus be horribly wrong. We can, however, use KBUILD_MODNAME as a

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Miguel Ojeda
On 9/28/07, Vegard Nossum [EMAIL PROTECTED] wrote: On 9/28/07, Miguel Ojeda [EMAIL PROTECTED] wrote: On 9/28/07, Vegard Nossum [EMAIL PROTECTED] wrote: reason we can't use KBUILD_MODNAME is that this is defined on the command line. The declaration inside the header would thus be horribly

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Miguel Ojeda
On 9/28/07, Vegard Nossum [EMAIL PROTECTED] wrote: On 9/27/07, Vegard Nossum [EMAIL PROTECTED] wrote: * Use SUBSYSTEM and KBUILD_MODNAME snip. 2.1.5. Subsystem/driver tags Many parts of the kernel already prefix their log messages with a subsystem and/or driver tag to identify

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/27/07, Vegard Nossum [EMAIL PROTECTED] wrote: * Use SUBSYSTEM and KBUILD_MODNAME snip. 2.1.5. Subsystem/driver tags Many parts of the kernel already prefix their log messages with a subsystem and/or driver tag to identify the source of a particular message. With the kprint

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/28/07, Kyle Moffett [EMAIL PROTECTED] wrote: On Sep 28, 2007, at 03:31:11, Geert Uytterhoeven wrote: Can't you store the loglevel in the kprint_block and check it in all successive kprint_*() macros? If gcc knows it's constant, it can optimize the non-wanted code away. As other fields

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
If-blocks spanning macros are really dangerous! E.g. an Ethernet driver may want to do: kprint_block(block, MAC ); for (i = 0; i 6; i++) { card-mac[i] = obtain_mac_byte_from_hw(i); kprint_block(block, %02x, card-mac[i]); } This

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Dick Streefland
Vegard Nossum [EMAIL PROTECTED] wrote: | It should be possible to optimize out multi-line (block) entries | based on log-level filtering even though the log-level is only given | in the first call (the initializer). It may take the shape of an | if-block that spans several macros. This is not

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Jan Engelhardt
On Sep 27 2007 23:18, Vegard Nossum wrote: * kprint_level() is better than kprint(level), ) because in the case of the default log-level, the argument can be omitted. * Memory allocated for entries and arguments is done in a ring-buffer with variable-sized chunks. Arguments are

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Rob Landley
On Friday 28 September 2007 7:11:03 am Vegard Nossum wrote: wrong. We can, however, use KBUILD_MODNAME as a default value for KPRINT_DRIVER, like: static const char *KPRINT_DRIVER = KBUILD_MODNAME; which would pre-process to something like: static const char *KPRINT_DRIVER = bcm43xx; Which

Re: [RFC] New kernel-message logging API (take 2)

2007-09-28 Thread Vegard Nossum
On 9/28/07, Rob Landley [EMAIL PROTECTED] wrote: On Friday 28 September 2007 7:11:03 am Vegard Nossum wrote: wrong. We can, however, use KBUILD_MODNAME as a default value for KPRINT_DRIVER, like: static const char *KPRINT_DRIVER = KBUILD_MODNAME; which would pre-process to something like:

Re: [RFC] New kernel-message logging API (take 2)

2007-09-27 Thread linux
> Example: { > struct kprint_block out; > kprint_block_init(, KPRINT_DEBUG); > kprint_block(, "Stack trace:"); > > while(unwind_stack()) { > kprint_block(, "%p %s", address, symbol); > } > kprint_block_flush(); > } Assuming that

[RFC] New kernel-message logging API (take 2)

2007-09-27 Thread Vegard Nossum
Hello, A big thanks to everybody who read and replied to my first e-mail; I have tried my best to incorporate your feedback and suggestions. I also added some CCs who recently participated in logging-related discussions. Changes (since Sept. 22): * Extensibility -> Allowing the compiler to

[RFC] New kernel-message logging API (take 2)

2007-09-27 Thread Vegard Nossum
Hello, A big thanks to everybody who read and replied to my first e-mail; I have tried my best to incorporate your feedback and suggestions. I also added some CCs who recently participated in logging-related discussions. Changes (since Sept. 22): * Extensibility - Allowing the compiler to

Re: [RFC] New kernel-message logging API (take 2)

2007-09-27 Thread linux
Example: { struct kprint_block out; kprint_block_init(out, KPRINT_DEBUG); kprint_block(out, Stack trace:); while(unwind_stack()) { kprint_block(out, %p %s, address, symbol); } kprint_block_flush(out); } Assuming that kprint_block_flush()

Re: [RFC] New kernel-message logging API

2007-09-25 Thread Miguel Ojeda
On 9/25/07, Vegard Nossum <[EMAIL PROTECTED]> wrote: > On 9/23/07, Miguel Ojeda <[EMAIL PROTECTED]> wrote: > > Nice. I would suggest having some kind of standard way to show the > > information on the screen/dmesg. I mean, instead of having plain lines > > being written to the log, having

Re: [RFC] New kernel-message logging API

2007-09-25 Thread Michael Holzheu
On Mon, 2007-09-24 at 08:19 -0700, Joe Perches wrote: > On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote: > > Together with the idea of not allowing multiple lines in the kprint_xxx > > functions, that would go with our approach having message numbers to > > identify a message. > > How

Re: [RFC] New kernel-message logging API

2007-09-25 Thread Vegard Nossum
On 9/25/07, Joe Perches <[EMAIL PROTECTED]> wrote: > On Tue, 2007-09-25 at 00:58 -0400, [EMAIL PROTECTED] wrote: > > Even the "kp_" prefix is actually pretty unnecessary. It's "info" > > and a human-readable string that make it recognizable as a log message. > > While I agree a prefix isn't

Re: [RFC] New kernel-message logging API

2007-09-25 Thread linux
>> Even the "kp_" prefix is actually pretty unnecessary. It's "info" >> and a human-readable string that make it recognizable as a log message. > While I agree a prefix isn't necessary, info, warn, err > are already frequently #define'd and used. > > kp_ isn't currently in use. > > $ egrep -r

Re: [RFC] New kernel-message logging API

2007-09-25 Thread Joe Perches
On Tue, 2007-09-25 at 00:58 -0400, [EMAIL PROTECTED] wrote: > Even the "kp_" prefix is actually pretty unnecessary. It's "info" > and a human-readable string that make it recognizable as a log message. While I agree a prefix isn't necessary, info, warn, err are already frequently #define'd and

Re: [RFC] New kernel-message logging API

2007-09-25 Thread Joe Perches
On Tue, 2007-09-25 at 00:58 -0400, [EMAIL PROTECTED] wrote: Even the kp_ prefix is actually pretty unnecessary. It's info and a human-readable string that make it recognizable as a log message. While I agree a prefix isn't necessary, info, warn, err are already frequently #define'd and used.

Re: [RFC] New kernel-message logging API

2007-09-25 Thread linux
Even the kp_ prefix is actually pretty unnecessary. It's info and a human-readable string that make it recognizable as a log message. While I agree a prefix isn't necessary, info, warn, err are already frequently #define'd and used. kp_level isn't currently in use. $ egrep -r -l

Re: [RFC] New kernel-message logging API

2007-09-25 Thread Vegard Nossum
On 9/25/07, Joe Perches [EMAIL PROTECTED] wrote: On Tue, 2007-09-25 at 00:58 -0400, [EMAIL PROTECTED] wrote: Even the kp_ prefix is actually pretty unnecessary. It's info and a human-readable string that make it recognizable as a log message. While I agree a prefix isn't necessary, info,

Re: [RFC] New kernel-message logging API

2007-09-25 Thread Michael Holzheu
On Mon, 2007-09-24 at 08:19 -0700, Joe Perches wrote: On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote: Together with the idea of not allowing multiple lines in the kprint_xxx functions, that would go with our approach having message numbers to identify a message. How does this

Re: [RFC] New kernel-message logging API

2007-09-25 Thread Miguel Ojeda
On 9/25/07, Vegard Nossum [EMAIL PROTECTED] wrote: On 9/23/07, Miguel Ojeda [EMAIL PROTECTED] wrote: Nice. I would suggest having some kind of standard way to show the information on the screen/dmesg. I mean, instead of having plain lines being written to the log, having something very

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Vegard Nossum
On 9/23/07, Miguel Ojeda <[EMAIL PROTECTED]> wrote: > Nice. I would suggest having some kind of standard way to show the > information on the screen/dmesg. I mean, instead of having plain lines > being written to the log, having something very short like: Thanks for the idea. Is this something

Re: [RFC] New kernel-message logging API

2007-09-24 Thread linux
> I don't know. Compare the following two lines: > > printk(KERN_INFO "Message.\n"); > kprint_info("Message."); > > By dropping the lengthy macro (it's not like it's going to change > while we're running anyway, so why not make it a part of the function > name?) and the final newline, we

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Rob Landley
On Monday 24 September 2007 7:10:32 pm Joe Perches wrote: > On Mon, 2007-09-24 at 18:51 -0500, Rob Landley wrote: > > > An added pass between gcc preprocessor and compiler could compact > > > or compress the format string without modifying the conversion > > > specifications so __attribute__

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Rob Landley
On Monday 24 September 2007 3:37:55 pm Vegard Nossum wrote: > On 9/24/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-09-24 at 18:43 +0200, Vegard Nossum wrote: > > > Storing the format-string separately allows us to hash THAT instead of > > > the formatted (ie. console output)

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Joe Perches
On Mon, 2007-09-24 at 18:51 -0500, Rob Landley wrote: > > An added pass between gcc preprocessor and compiler could compact > > or compress the format string without modifying the conversion > > specifications so __attribute__ ((format (printf)) would still work. > This does not address my

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Rob Landley
On Monday 24 September 2007 10:19:16 am Joe Perches wrote: > On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote: > > Together with the idea of not allowing multiple lines in the kprint_xxx > > functions, that would go with our approach having message numbers to > > identify a message. > >

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Vegard Nossum
On 9/24/07, Joe Perches <[EMAIL PROTECTED]> wrote: > On Mon, 2007-09-24 at 18:43 +0200, Vegard Nossum wrote: > > Storing the format-string separately allows us to hash THAT instead of > > the formatted (ie. console output) message. Since this will never > > change from message to message, it can

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Jesse Barnes
On Saturday, September 22, 2007 12:27 pm Vegard Nossum wrote: > enum kprint_loglevel { > KPRINT_EMERG, /* kprint_emerg() */ > KPRINT_ALERT, /* kprint_alert() */ > KPRINT_CRIT,/* kprint_crit() */ > KPRINT_ERROR, /* kprint_error() and/or kprint_err() */ >

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Joe Perches
On Mon, 2007-09-24 at 18:43 +0200, Vegard Nossum wrote: > Storing the format-string separately allows us to hash THAT instead of > the formatted (ie. console output) message. Since this will never > change from message to message, it can be looked up in a table or > whatever and allow user-space

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Vegard Nossum
On 9/24/07, Joe Perches <[EMAIL PROTECTED]> wrote: > On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote: > > Together with the idea of not allowing multiple lines in the kprint_xxx > > functions, that would go with our approach having message numbers to > > identify a message. > > How does

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Joe Perches
On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote: > Together with the idea of not allowing multiple lines in the kprint_xxx > functions, that would go with our approach having message numbers to > identify a message. How does this equate/give message numbers? > If you do it like that,

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Michael Holzheu
Hi Vegard, On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: > After recent discussions on LKML and a general dissatisfaction at the > current printk() kernel-message logging interface, I've decided to > write down some of the ideas for a better system. Good luck :-) [snip] > Example: {

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Michael Holzheu
Hi Vegard, On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: After recent discussions on LKML and a general dissatisfaction at the current printk() kernel-message logging interface, I've decided to write down some of the ideas for a better system. Good luck :-) [snip] Example: {

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Joe Perches
On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote: Together with the idea of not allowing multiple lines in the kprint_xxx functions, that would go with our approach having message numbers to identify a message. How does this equate/give message numbers? If you do it like that, you

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Vegard Nossum
On 9/24/07, Joe Perches [EMAIL PROTECTED] wrote: On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote: Together with the idea of not allowing multiple lines in the kprint_xxx functions, that would go with our approach having message numbers to identify a message. How does this

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Joe Perches
On Mon, 2007-09-24 at 18:43 +0200, Vegard Nossum wrote: Storing the format-string separately allows us to hash THAT instead of the formatted (ie. console output) message. Since this will never change from message to message, it can be looked up in a table or whatever and allow user-space to do

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Jesse Barnes
On Saturday, September 22, 2007 12:27 pm Vegard Nossum wrote: enum kprint_loglevel { KPRINT_EMERG, /* kprint_emerg() */ KPRINT_ALERT, /* kprint_alert() */ KPRINT_CRIT,/* kprint_crit() */ KPRINT_ERROR, /* kprint_error() and/or kprint_err() */

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Vegard Nossum
On 9/24/07, Joe Perches [EMAIL PROTECTED] wrote: On Mon, 2007-09-24 at 18:43 +0200, Vegard Nossum wrote: Storing the format-string separately allows us to hash THAT instead of the formatted (ie. console output) message. Since this will never change from message to message, it can be looked

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Rob Landley
On Monday 24 September 2007 10:19:16 am Joe Perches wrote: On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote: Together with the idea of not allowing multiple lines in the kprint_xxx functions, that would go with our approach having message numbers to identify a message. How does

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Joe Perches
On Mon, 2007-09-24 at 18:51 -0500, Rob Landley wrote: An added pass between gcc preprocessor and compiler could compact or compress the format string without modifying the conversion specifications so __attribute__ ((format (printf)) would still work. This does not address my problem.

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Rob Landley
On Monday 24 September 2007 3:37:55 pm Vegard Nossum wrote: On 9/24/07, Joe Perches [EMAIL PROTECTED] wrote: On Mon, 2007-09-24 at 18:43 +0200, Vegard Nossum wrote: Storing the format-string separately allows us to hash THAT instead of the formatted (ie. console output) message. Since

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Rob Landley
On Monday 24 September 2007 7:10:32 pm Joe Perches wrote: On Mon, 2007-09-24 at 18:51 -0500, Rob Landley wrote: An added pass between gcc preprocessor and compiler could compact or compress the format string without modifying the conversion specifications so __attribute__ ((format

Re: [RFC] New kernel-message logging API

2007-09-24 Thread linux
I don't know. Compare the following two lines: printk(KERN_INFO Message.\n); kprint_info(Message.); By dropping the lengthy macro (it's not like it's going to change while we're running anyway, so why not make it a part of the function name?) and the final newline, we actually end up

Re: [RFC] New kernel-message logging API

2007-09-24 Thread Vegard Nossum
On 9/23/07, Miguel Ojeda [EMAIL PROTECTED] wrote: Nice. I would suggest having some kind of standard way to show the information on the screen/dmesg. I mean, instead of having plain lines being written to the log, having something very short like: Thanks for the idea. Is this something you

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Rob Landley
On Saturday 22 September 2007 2:27:29 pm Vegard Nossum wrote: > After recent discussions on LKML and a general dissatisfaction at the > current printk() kernel-message logging interface, I've decided to > write down some of the ideas for a better system. > > > Requirements > > > *

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Joe Perches
On Sun, 2007-09-23 at 10:45 +0200, Jan Engelhardt wrote: > I'd rather fix up code to reduce its indent rather than > trying microoptimizations at the function name level! I think that's a different discussion. You could fix some of them whenever you like. $ egrep -r -l --include=*.c

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Joe Perches
On Sun, 2007-09-23 at 10:39 +0200, Vegard Nossum wrote: > On 9/23/07, Joe Perches <[EMAIL PROTECTED]> wrote: > > Given the number of 80 column zealots, character naming length > > matters. > I don't know. Compare the following two lines: > printk(KERN_INFO "Message.\n"); > kprint_info("Message.");

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Jan Engelhardt
On Sep 23 2007 11:20, Vegard Nossum wrote: >> >printk(KERN_INFO "Message.\n"); >> >kprint_info("Message."); >> >> I'd rather fix up code to reduce its indent rather than >> trying microoptimizations at the function name level! > >Well, that's a different discussion, really. Is fixing the body of

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Vegard Nossum
On 9/23/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Sep 23 2007 10:39, Vegard Nossum wrote: > >On 9/23/07, Joe Perches <[EMAIL PROTECTED]> wrote: > >> On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: > >> > #define kprint(fmt, ...) > >> > >> Good ideas. Perhaps a prefix of klog or

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Jan Engelhardt
On Sep 23 2007 10:39, Vegard Nossum wrote: >On 9/23/07, Joe Perches <[EMAIL PROTECTED]> wrote: >> On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: >> > #define kprint(fmt, ...) >> >> Good ideas. Perhaps a prefix of klog or kp_ instead? >> Given the number of 80 column zealots, character

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Vegard Nossum
On 9/23/07, Joe Perches <[EMAIL PROTECTED]> wrote: > On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: > > #define kprint(fmt, ...) > > Good ideas. Perhaps a prefix of klog or kp_ instead? > Given the number of 80 column zealots, character naming length matters. I don't know. Compare the

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Vegard Nossum
On 9/23/07, Joe Perches [EMAIL PROTECTED] wrote: On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: #define kprint(fmt, ...) Good ideas. Perhaps a prefix of klog or kp_ instead? Given the number of 80 column zealots, character naming length matters. I don't know. Compare the following

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Jan Engelhardt
On Sep 23 2007 10:39, Vegard Nossum wrote: On 9/23/07, Joe Perches [EMAIL PROTECTED] wrote: On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: #define kprint(fmt, ...) Good ideas. Perhaps a prefix of klog or kp_ instead? Given the number of 80 column zealots, character naming length

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Vegard Nossum
On 9/23/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On Sep 23 2007 10:39, Vegard Nossum wrote: On 9/23/07, Joe Perches [EMAIL PROTECTED] wrote: On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: #define kprint(fmt, ...) Good ideas. Perhaps a prefix of klog or kp_ instead? Given

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Jan Engelhardt
On Sep 23 2007 11:20, Vegard Nossum wrote: printk(KERN_INFO Message.\n); kprint_info(Message.); I'd rather fix up code to reduce its indent rather than trying microoptimizations at the function name level! Well, that's a different discussion, really. Is fixing the body of [v]printk()

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Joe Perches
On Sun, 2007-09-23 at 10:45 +0200, Jan Engelhardt wrote: I'd rather fix up code to reduce its indent rather than trying microoptimizations at the function name level! I think that's a different discussion. You could fix some of them whenever you like. $ egrep -r -l --include=*.c

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Joe Perches
On Sun, 2007-09-23 at 10:39 +0200, Vegard Nossum wrote: On 9/23/07, Joe Perches [EMAIL PROTECTED] wrote: Given the number of 80 column zealots, character naming length matters. I don't know. Compare the following two lines: printk(KERN_INFO Message.\n); kprint_info(Message.); The problem

Re: [RFC] New kernel-message logging API

2007-09-23 Thread Rob Landley
On Saturday 22 September 2007 2:27:29 pm Vegard Nossum wrote: After recent discussions on LKML and a general dissatisfaction at the current printk() kernel-message logging interface, I've decided to write down some of the ideas for a better system. Requirements * Backwards

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Kyle Moffett
On Sep 22, 2007, at 20:47:21, Joe Perches wrote: On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote: Severity is *exactly* "desirability of logging". Disagree. What's info to someone is an alert to someone else. The problem is the valuation of the reasoning. It's all opinion. For

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Miguel Ojeda
On 9/22/07, Vegard Nossum <[EMAIL PROTECTED]> wrote: > After recent discussions on LKML and a general dissatisfaction at the > current printk() kernel-message logging interface, I've decided to > write down some of the ideas for a better system. Nice. I would suggest having some kind of standard

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Joe Perches
On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote: > Severity is *exactly* "desirability of logging". Disagree. What's info to someone is an alert to someone else. The problem is the valuation of the reasoning. It's all opinion. cheers, Joe - To unsubscribe from this list: send the line

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Kyle Moffett
On Sep 22, 2007, at 20:13:03, Joe Perches wrote: On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: Additionally, this would allow the compiler to completely optimize out calls that are below a certain log-level severity level [2][3]. Severity doesn't really equate to desire to log.

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Joe Perches
On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: > #define kprint(fmt, ...) Good ideas. Perhaps a prefix of klog or kp_ instead? Given the number of 80 column zealots, character naming length matters. > Additionally, this would allow the compiler to completely optimize out > calls that

[RFC] New kernel-message logging API

2007-09-22 Thread Vegard Nossum
After recent discussions on LKML and a general dissatisfaction at the current printk() kernel-message logging interface, I've decided to write down some of the ideas for a better system. Requirements * Backwards compatibility with printk(), syslog(), etc. There is no way the whole

[RFC] New kernel-message logging API

2007-09-22 Thread Vegard Nossum
After recent discussions on LKML and a general dissatisfaction at the current printk() kernel-message logging interface, I've decided to write down some of the ideas for a better system. Requirements * Backwards compatibility with printk(), syslog(), etc. There is no way the whole

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Joe Perches
On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: #define kprint(fmt, ...) Good ideas. Perhaps a prefix of klog or kp_ instead? Given the number of 80 column zealots, character naming length matters. Additionally, this would allow the compiler to completely optimize out calls that are

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Kyle Moffett
On Sep 22, 2007, at 20:13:03, Joe Perches wrote: On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote: Additionally, this would allow the compiler to completely optimize out calls that are below a certain log-level severity level [2][3]. Severity doesn't really equate to desire to log.

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Joe Perches
On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote: Severity is *exactly* desirability of logging. Disagree. What's info to someone is an alert to someone else. The problem is the valuation of the reasoning. It's all opinion. cheers, Joe - To unsubscribe from this list: send the line

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Miguel Ojeda
On 9/22/07, Vegard Nossum [EMAIL PROTECTED] wrote: After recent discussions on LKML and a general dissatisfaction at the current printk() kernel-message logging interface, I've decided to write down some of the ideas for a better system. Nice. I would suggest having some kind of standard way

Re: [RFC] New kernel-message logging API

2007-09-22 Thread Kyle Moffett
On Sep 22, 2007, at 20:47:21, Joe Perches wrote: On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote: Severity is *exactly* desirability of logging. Disagree. What's info to someone is an alert to someone else. The problem is the valuation of the reasoning. It's all opinion. For