Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1458988 > unrolled thread

Re: [PATCH V3] printk: Create pr_<level> functions

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V3] printk: Create pr_<level> functions Geert Uytterhoeven <geert@linux-m68k.org> - 2016-08-09 19:10 +0200
    Re: [PATCH V3] printk: Create pr_<level> functions Joe Perches <joe@perches.com> - 2016-08-09 19:10 +0200
    Re: [PATCH V3] printk: Create pr_<level> functions Joe Perches <joe@perches.com> - 2016-08-09 19:40 +0200

#1458988 — Re: [PATCH V3] printk: Create pr_<level> functions

Hi Joe,

On Fri, Jun 24, 2016 at 5:46 AM, Joe Perches <joe@perches.com> wrote:
> Using functions instead of macros can reduce overall code size
> by eliminating unnecessary "KERN_SOH<digit>" prefixes from
> format strings.

This change, commit 874f9c7da9a4acbc1 upstream, seems to have an
(unintendent?) side-effect.

Before, pr_*() calls without a trailing newline characters would be printed
with a newline character appended, both on the console and in the output
of the dmesg command.
After this commit, no new line character is appended, and the output of
the next pr_*() call of the same type may be appended, like in:

  - Truncating RAM at 0x0000000040000000-0x00000000c0000000 to
-0x0000000070000000
  - Ignoring RAM at 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)
  + Truncating RAM at 0x0000000040000000-0x00000000c0000000 to
-0x0000000070000000Ignoring RAM at
0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)

I don't know why this is happening, hence I had to use git bisect to find
the offending commit.

Was this change intentional?
I guess it wouldn't hurt to send patches to add an explicit trailing newline
characters to messages that lack it?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [next] | [standalone]

#1458993

On Tue, 2016-08-09 at 19:01 +0200, Geert Uytterhoeven wrote:
> Hi Joe,

Hi Geert

> On Fri, Jun 24, 2016 at 5:46 AM, Joe Perches <joe@perches.com> wrote:
> > Using functions instead of macros can reduce overall code size
> > by eliminating unnecessary "KERN_SOH" prefixes from
> > format strings.

> This change, commit 874f9c7da9a4acbc1 upstream, seems to have an
> (unintendent?) side-effect.
> 
> Before, pr_*() calls without a trailing newline characters would be printed
> with a newline character appended, both on the console and in the output
> of the dmesg command.
> After this commit, no new line character is appended, and the output of
> the next pr_*() call of the same type may be appended, like in:
> 
>   - Truncating RAM at 0x0000000040000000-0x00000000c0000000 to
> -0x0000000070000000
>   - Ignoring RAM at 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)
>   + Truncating RAM at 0x0000000040000000-0x00000000c0000000 to
> -0x0000000070000000Ignoring RAM at
> 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)
> 
> I don't know why this is happening, hence I had to use git bisect to find
> the offending commit.
> 
> Was this change intentional?

No, that is not intentional.
Thanks for the report, I'll look at it.

> I guess it wouldn't hurt to send patches to add an explicit trailing newline
> characters to messages that lack it?

Always true.

[toc] | [prev] | [next] | [standalone]

#1459031

On Tue, 2016-08-09 at 19:01 +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 24, 2016 at 5:46 AM, Joe Perches <joe@perches.com> wrote:
> > Using functions instead of macros can reduce overall code size
> > by eliminating unnecessary "KERN_SOH" prefixes from
> > format strings.
> This change, commit 874f9c7da9a4acbc1 upstream, seems to have an
> (unintendent?) side-effect.
> 
> Before, pr_*() calls without a trailing newline characters would be printed
> with a newline character appended, both on the console and in the output
> of the dmesg command.
> After this commit, no new line character is appended, and the output of
> the next pr_*() call of the same type may be appended, like in:
> 
>   - Truncating RAM at 0x0000000040000000-0x00000000c0000000 to
> -0x0000000070000000
>   - Ignoring RAM at 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)
>   + Truncating RAM at 0x0000000040000000-0x00000000c0000000 to
> -0x0000000070000000Ignoring RAM at
> 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)
> 
> I don't know why this is happening, hence I had to use git bisect to find
> the offending commit.

The newline handling code inside vprintk_emit is a bit
involved and for now I suggest a revert until this has
all the same behavior as earlier.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web