lkml.org 
[lkml]   [2004]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Console: fall back to /dev/null when no console is availlable
    On Wed, 6 Oct 2004, [iso-8859-1] Jörn Engel wrote:
    > On Wed, 6 October 2004 15:07:05 +0200, Geert Uytterhoeven wrote:
    > > On Wed, 6 Oct 2004, [iso-8859-1] Jörn Engel wrote:
    > > > Point is that above patch is simpler and empiria didn't give me a
    > > > reason to worry about anything else.
    > >
    > > I'll give you another reason :-)
    > >
    > > If I do have multiple active struct consoles registered (e.g. normal tty0 or
    > > ttyS0 and a debug console without a real tty), and the /dev/console demux
    > > thinks the debug console is the real one (the one opened if you open
    > > /dev/console), printk() messages will appear on both active consoles, but
    > > /dev/console cannot be opened.
    > >
    > > To avoid this problem, the /dev/console demux should walk the list of active
    > > consoles until it finds one that can be opened, or fall back to /dev/null if
    > > none is found.
    > >
    > > Does that sound reasonable?
    >
    > Not to me, no. But I was wrong before.
    >
    > Having no console at all is a valid design. It used to cause

    One problem is that `console' means multiple things:
    1. The output device for printk() (multiple consoles are allowed, cfr.
    multiple console= kernel parameters and debug-only consoles)
    2. The tty (both input and output) for /sbin/init (only one instance, cfr.
    the last console= kernel parameter)

    I suggested to change the logic for 2 not to use the last console= kernel
    parameter if it turns out not to support input (cfr. the return value of struct
    console.device()), but try the other registered struct consoles.

    > problems, my patch fixes them. A command-line option like
    > "console=/dev/null" doesn't fix it because it doesn't do what it
    > appears to do at first glance, so the patch is needed.

    Indeed. Because the /dev/null driver doesn't call register_console().
    It could be made to work that way (`console=null'), though, but make sure to
    register your null-console _first_.
    But I think it's simpler to just check console->device() and take appropriate
    actions.

    > Having a non-working console, esp. for debug, is a rather odd design.
    > My approach would be to either explicitly tell the kernel to use the
    > other as default console via "console=/dev/ttyS0" or not have the
    > debug thing in the kernel in the first place. Either way, no patch is
    > needed.

    It was not `designed' to be that way. But due to how `the console' (nr. 2 from
    above) works, registration order matters. If people make the mistake (or just
    forget) to say `console=ttyS0', a debug console registered later causes
    problems.

    And the reason the debug consoles (read: capturers) use register_console() is
    to avoid code duplication.

    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
    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:3.429 / U:0.416 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site