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
15 matches
Mail list logo
