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 somet
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";
W
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 thu
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 t
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 variab
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
> 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]);
>
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-
>linked
"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 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 sto
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
> 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 kpr
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 el
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
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 doe
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 necess
>> 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 -l
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 us
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
> 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
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__ ((form
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.
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 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
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
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() */
> KPRIN
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
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 th
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
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 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
>
>
> * Bac
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 "^[[:cntrl:]
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 na
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 fo
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 st
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 w
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 "u
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. I'd
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 ar
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
45 matches
Mail list logo
