From: Adam Simonelli <adamsimonelli@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
Jiri Slaby <jirislaby@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH v5 1/2] ttynull: Add an option to allow ttynull to be used as a console device
Date: Mon, 03 Mar 2025 22:52:29 -0500 [thread overview]
Message-ID: <4647568.Icojqenx9y@nerdopolis2> (raw)
In-Reply-To: <Z8Wsi7_rvk346Snr@pathway.suse.cz>
On Monday, March 3, 2025 8:20:11 AM EST Petr Mladek wrote:
> On Wed 2025-02-26 08:39:23, Adam Simonelli wrote:
> > On Tuesday, February 25, 2025 11:19:04 AM EST Petr Mladek wrote:
> > > On Mon 2025-02-24 07:39:14, adamsimonelli@gmail.com wrote:
> > > > From: Adam Simonelli <adamsimonelli@gmail.com>
> > > >
> > > > The new config option, CONFIG_NULL_TTY_CONSOLE will allow ttynull to be
> > > > initialized by console_initcall() and selected as a possible console
> > > > device.
> > > >
> > > > diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c
> > > > index 6b2f7208b564..ec3dd3fd41c0 100644
> > > > --- a/drivers/tty/ttynull.c
> > > > +++ b/drivers/tty/ttynull.c
> > > > @@ -57,6 +57,13 @@ static struct tty_driver *ttynull_device(struct console *c, int *index)
> > > > static struct console ttynull_console = {
> > > > .name = "ttynull",
> > > > .device = ttynull_device,
> > > > +
> > > > + /*
> > > > + * Match the index and flags from other boot consoles when CONFIG_NULL_TTY_CONSOLE is
> > > > + * enabled, otherwise, use the default values for the index and flags.
> > > > + */
> > > > + .index = IS_ENABLED(CONFIG_NULL_TTY_CONSOLE) ? -1 : 0,
> > >
> > > This should not be needed. "con->index" is always initialized to "0"
> > > for the default console, see:
> > >
> > OK, I had this in an #ifdef before, it was the cleanest way to set it to -1
> > that I could think of, other than the ifdef... If I still need this, I will try
> > to think of something else to set it to -1 when the option is enabled
>
> Ah, I was not clear enough. It should be perfectly fine to always
> statically initialize the value to -1. We should not need any
> #ifdef or IS_ENABLED.
>
> I mean to do:
>
> static struct console ttynull_console = {
> .name = "ttynull",
> .device = ttynull_device,
> .index = -1,
> };
>
> We might even do this in a separate patch. IMHO, it should have
> been done this way since the beginning.
>
OK, will do. This makes sense.
> > > static void try_enable_default_console(struct console *newcon)
> > > {
> > > if (newcon->index < 0)
> > > newcon->index = 0;
> > > [...]
> > > }
> > >
> > > > + .flags = IS_ENABLED(CONFIG_NULL_TTY_CONSOLE) ? CON_PRINTBUFFER : 0,
> > >
> > > This does not make much sense to me.
> > >
> > > CON_PRINTBUFFER prevents duplicated output when the same device has
> > > already been registered as a boot console. But ttynull does not have
> > > a boot console variant. Also it is a "null" device. It never prints
> > > anything. The output could never be duplicated by definition.
> > >
> > OK, I was duplicating what I saw in other consoles. I can try to remove it
>
> Again, I was not clear enough. My primary concern was that it did not make
> much sense to use the IS_ENABLED() check and initialize the value
> different way.
>
> Anyway, I would omit the flag. It is a NULL device. It does not matter
> whether it prints existing (old) messages during registration or not.
>
Understood, this makes sense.
> > > > };
> > > >
> > > My proposal is to call:
> > >
> > > #ifdef CONFIG_NULL_TTY_DEFAULT_CONSOLE
> > > static int __init ttynull_default_console(void)
> > > {
> > > add_preferred_console("ttynull", 0, NULL);
> > > return 0;
> > > }
> > > console_initcall(ttynull_register);
> > > #endif
> > >
> > OK, actually in earlier revisions locally, I did actually have
> >
> >
> >
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index dddb15f48d59..c1554a789de8 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -3712,6 +3712,11 @@ void __init console_init(void)
> > initcall_t call;
> > initcall_entry_t *ce;
> >
> > +#ifdef CONFIG_NULL_TTY_CONSOLE
> > + if (!strstr(boot_command_line, "console="))
> > + add_preferred_console("ttynull", 0, NULL);
>
> Good point! We should call add_preferred_console() only when
> the is no console= command line parameter. Otherwise, it could
> not get overridden by the command line.
>
> We could check "console_set_on_cmdline", similar to
> xenfb_make_preferred_console().
>
> > +#endif
> > +
> > /* Setup the default TTY line discipline. */
> > n_tty_init();
> >
> > Which worked as far as I could tell, at least on x86. Not sure if that was the
> > right place,
>
> I would prefer to keep it in drivers/tty/ttynull.c when possible.
> The following might do the trick:
>
> #ifdef CONFIG_NULL_TTY_DEFAULT_CONSOLE
> static int __init ttynull_default_console(void)
> {
> if (!console_set_on_cmdline)
> add_preferred_console("ttynull", 0, NULL);
>
> return 0;
> }
> console_initcall(ttynull_register);
> #endif
>
> Best Regards,
> Petr
>
Thanks for that, that works.
next prev parent reply other threads:[~2025-03-04 3:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 12:39 [PATCH v5 0/2] Optionally allow ttynull to be selected as a default console adamsimonelli
2025-02-24 12:39 ` [PATCH v5 1/2] ttynull: Add an option to allow ttynull to be used as a console device adamsimonelli
2025-02-25 16:19 ` Petr Mladek
2025-02-26 13:39 ` Adam Simonelli
2025-02-26 19:22 ` Andy Shevchenko
2025-02-28 4:39 ` Adam Simonelli
2025-02-28 18:59 ` Andy Shevchenko
2025-03-03 13:20 ` Petr Mladek
2025-03-04 3:52 ` Adam Simonelli [this message]
2025-02-24 12:39 ` [PATCH v5 2/2] tty: Change order of ttynull to be linked sooner if enabled as a console adamsimonelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4647568.Icojqenx9y@nerdopolis2 \
--to=adamsimonelli@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.