linux-kernel - Re: [RFC PATCH] printk: console: Allow each console to have its own loglevel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdU2tUU6FAM-nK9oxd0GwcO3WwvZp9Um4=w5By+N0P0kXA@mail.gmail.com>
Date:   Thu, 19 May 2022 09:26:37 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Chris Down <chris@...isdown.name>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Petr Mladek <pmladek@...e.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [RFC PATCH] printk: console: Allow each console to have its own loglevel

Hi Chris,

On Wed, May 18, 2022 at 4:27 PM Chris Down <chris@...isdown.name> wrote:
> [Once the goals of this patch are generally agreed upon, it can be split
> out further with more detailed changelogs if desired.]
>
> Consoles can have vastly different latencies and throughputs. For
> example, writing a message to the serial console can take on the order
> of tens of milliseconds to get the UART to successfully write a message.
> While this might be fine for a single, one-off message, this can cause
> significant application-level stalls in situations where the kernel
> writes large amounts of information to the console.
>
> This means that while you might want to send at least INFO level
> messages to (for example) netconsole, which is relatively fast, you may
> only want to send at least WARN level messages to the serial console.
> Such an implementation would permit debugging using the serial console
> in cases that netconsole doesn't receive messages during particularly
> bad system issues, while still keeping the noise low enough to avoid
> inducing latency in userspace applications. This patch adds such an
> interface, extending the existing console loglevel controls to allow
> each console to have its own loglevel.

Thanks, this looks like an interesting idea!

> --- a/Documentation/admin-guide/serial-console.rst
> +++ b/Documentation/admin-guide/serial-console.rst
> @@ -17,7 +17,7 @@ use for console output.
>
>  The format of this option is::
>
> -       console=device,options
> +       console=device,options/loglevel
>
>         device:         tty0 for the foreground virtual console
>                         ttyX for any other virtual console
> @@ -32,15 +32,23 @@ The format of this option is::
>                         and F is flow control ('r' for RTS). Default is
>                         9600n8. The maximum baudrate is 115200.
>
> +       loglevel:       optional. a number can be provided from 0
> +                       (LOGLEVEL_EMERG) to 8 (LOGLEVEL_DEBUG + 1), and
> +                       messages below that will be emitted onto the console as
> +                       they become available.
> +
>  You can specify multiple console= options on the kernel command line.
>  Output will appear on all of them. The last device will be used when
>  you open ``/dev/console``. So, for example::
>
> -       console=ttyS1,9600 console=tty0
> +       console=ttyS1,9600/5 console=tty0
>
>  defines that opening ``/dev/console`` will get you the current foreground
> -virtual console, and kernel messages will appear on both the VGA
> -console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.
> +virtual console, and kernel messages will appear on both the VGA console and
> +the 2nd serial port (ttyS1 or COM2) at 9600 baud. The optional loglevel "5"
> +indicates that this console will emit messages more serious than
> +LOGLEVEL_NOTICE (that is, LOGLEVEL_WARNING and below, since more serious
> +messages have lower ordering).
>
>  Note that you can only define one console per device type (serial, video).

All of the above options are appropriate for "classic" systems,
where the console device is selected using the "console=" option.

On systems using Device tree, the serial console device is selected
using the "chosen/stout-path" property in DT, and the graphical
console is usually auto-detected and auto-enabled through DRM.
Do you envision a way to specify a specific console loglevel on the
kernel command line on such systems?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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