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
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";
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
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
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
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
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
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
> 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]);
> }
>
>
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-
>
"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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
> 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
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
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
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()
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
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
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
>> 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
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
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.
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
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,
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
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
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
> 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
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__
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)
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
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.
>
>
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
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() */
>
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
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
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,
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: {
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: {
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
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
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
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() */
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
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
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.
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
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
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
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
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
>
>
> *
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
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.");
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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
90 matches
Mail list logo