Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1499824
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: linux.git: printk() problem |
| Date | 2016-10-12 19:00 +0200 |
| Message-ID | <srv2N-73S-13@gated-at.bofh.it> (permalink) |
| References | <srrVg-52p-27@gated-at.bofh.it> <srtX3-6nc-3@gated-at.bofh.it> <sruq5-6PD-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, Oct 12, 2016 at 9:16 AM, Joe Perches <joe@perches.com> wrote:
>> (but with the new world order you actually *can* combine KERN_CONT
>> with a loglevel, so that if the beginning od the line got flushed, the
>> continuation can still be printed with the right log level).
>
> I think that might not be a good idea.
>
> Anything that uses a KERN_CONT with a new log level
> might as well be converted into multiple printks.
Generally yes.
The immediate reason for it was some really really nasty and horrible
indirection in the ACPI layer, which goes through something like
fifteen million different abstraction layers before it actually hits
"printk()", and some of them do vsprintf() in the middle.
It was something like ACPI_INFO() -> acpi_os_printf() ->
acpi_os_vprintf() which is completely broken and *always* has that
KERN_CONT marker at the beginning, but earlier phases can have the
level marker in it already..
In other words, it was a terminally broken piece of nasty code, but
there was no way I was going to touch the ACPI "OS independent"
layers, so I just said "screw this, if you want to mix KERN_CONT with
a level marker, you can".
So I agree, you normally shouldn't need to. In fact, the fewer
KERN_CONT's I see in the kernel, the better off we are. But
_sometimes_ KERN_CONT makes sense (and the OOM code is likely one of
the few places where it really might be the best of a number of bad
options: lots of information that needs to be pretty dense, and we
obviously can't afford to allocate a buffer for it dynamically, and
doing so statically isn't a great option either..)
Linus
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
linux.git: printk() problem Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-10-12 15:40 +0200
Re: linux.git: printk() problem Michal Hocko <mhocko@kernel.org> - 2016-10-12 17:00 +0200
Re: linux.git: printk() problem Joe Perches <joe@perches.com> - 2016-10-12 18:10 +0200
Re: linux.git: printk() problem Michal Hocko <mhocko@kernel.org> - 2016-10-13 08:30 +0200
Re: linux.git: printk() problem Joe Perches <joe@perches.com> - 2016-10-13 11:40 +0200
Re: linux.git: printk() problem Michal Hocko <mhocko@kernel.org> - 2016-10-13 12:10 +0200
Re: linux.git: printk() problem Joe Perches <joe@perches.com> - 2016-10-13 12:30 +0200
Re: linux.git: printk() problem Michal Hocko <mhocko@kernel.org> - 2016-10-13 13:10 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-12 17:50 +0200
Re: linux.git: printk() problem Joe Perches <joe@perches.com> - 2016-10-12 18:20 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-12 19:00 +0200
[PATCH] acpi_os_vprintf: Use printk_get_level() to avoid unnecessary KERN_CONT Joe Perches <joe@perches.com> - 2016-10-12 21:00 +0200
Re: [PATCH] acpi_os_vprintf: Use printk_get_level() to avoid unnecessary KERN_CONT "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-10-14 00:10 +0200
Re: linux.git: printk() problem Geert Uytterhoeven <geert@linux-m68k.org> - 2016-10-23 11:30 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-23 20:20 +0200
Re: linux.git: printk() problem Joe Perches <joe@perches.com> - 2016-10-23 21:10 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-23 21:40 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-23 21:50 +0200
Re: linux.git: printk() problem Geert Uytterhoeven <geert@linux-m68k.org> - 2016-10-24 13:20 +0200
Re: linux.git: printk() problem Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-10-24 16:20 +0200
Re: linux.git: printk() problem Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-10-24 16:30 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-24 20:00 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-24 20:00 +0200
Re: linux.git: printk() problem Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-25 04:00 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-25 04:10 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-25 04:30 +0200
Re: linux.git: printk() problem Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-25 06:10 +0200
Re: linux.git: printk() problem Joe Perches <joe@perches.com> - 2016-10-25 06:20 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-25 06:30 +0200
Re: linux.git: printk() problem Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-25 06:50 +0200
Re: linux.git: printk() problem Petr Mladek <pmladek@suse.com> - 2016-10-25 16:50 +0200
Re: linux.git: printk() problem Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-25 04:30 +0200
Re: linux.git: printk() problem Joe Perches <joe@perches.com> - 2016-10-23 22:40 +0200
Re: linux.git: printk() problem Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-23 23:20 +0200
Re: linux.git: printk() problem Steven Rostedt <rostedt@goodmis.org> - 2016-10-25 16:50 +0200
csiph-web