public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Down <chris@chrisdown.name>
To: Petr Mladek <pmladek@suse.com>
Cc: linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	John Ogness <john.ogness@linutronix.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	kernel-team@fb.com
Subject: Re: [PATCH v3 1/2] printk: console: Create console= parser that supports named options
Date: Mon, 5 Sep 2022 15:43:53 +0100	[thread overview]
Message-ID: <YxYLKU8TWZ4T5ONF@chrisdown.name> (raw)
In-Reply-To: <Yw80MmyBl4js09If@alley>

Hi Petr,

Thanks a lot for looking this over!

Petr Mladek writes:
>I think that the function does not work as expected.
>
>> +	bool seen_serial_opts = false;
>> +	char *key;
>> +
>> +	while ((key = strsep(&options, ",")) != NULL) {
>> +		char *value;
>
>strsep() replaces ',' with '\0'.
>
>> +
>> +		value = strchr(key, ':');
>> +		if (value)
>> +			*(value++) = '\0';
>
>This replaces ':' with '\0'.
>
>> +
>> +		if (!seen_serial_opts && isdigit(key[0]) && !value) {
>
>This catches the classic options in the format "bbbbpnf".
>
>> +			seen_serial_opts = true;
>> +			c->options = key;
>> +			continue;
>> +		}
>> +
>> +		pr_err("ignoring invalid console option: '%s%s%s'\n", key,
>> +		       value ? ":" : "", value ?: "");
>
>IMHO, this would warn even about "io", "mmio", ...  that are used by:

Oh dear, I should have known it won't be that simple :-D

>
>		console=uart[8250],io,<addr>[,options]
>		console=uart[8250],mmio,<addr>[,options]
>
>Warning: I am not completely sure about this. It seems that
>	 this format is handled by univ8250_console_match().
>
>	 IMHO, the "8250" is taken as "idx" in console_setup().
>	 And "idx" parameter is ignored by univ8250_console_match().
>	 This probably explains why "8250" is optional in console=
>	 parameter.
>
>> +	}
>> +}
>
>Sigh, the parsing of console= parameter is really hacky. Very old code.
>The name and idx is handled in console_setup(). The rest
>is handled by particular drivers via "options".
>
>This patch makes it even more tricky. It tries to handle some
>*options in add_preferred_console(). But it replaces all ','
>and ':' by '\0' so that drivers do not see the original *options
>any longer.

Other than the mmio/io stuff, I think it works properly, right? Maybe I'm 
missing something? :-)

Here's a userspace test for the parser that seems to work.  
parse_console_cmdline_options() should also ignore empty options instead of 
warning, but it still functions correctly in that case, it's just noisy right 
now.

---

/* Only change is pr_err to fprintf */

#define _DEFAULT_SOURCE

#include <stdio.h>
#include <string.h>
#include <stdbool.h>
#include <ctype.h>
#include <stdlib.h>

#define clamp(a, b, c) (a)
#define CON_LOGLEVEL 128

struct console_cmdline {
	char *options;
	int level;
	short flags;
};

static void parse_console_cmdline_options(struct console_cmdline *c,
					  char *options)
{
	bool seen_serial_opts = false;
	char *key;

	while ((key = strsep(&options, ",")) != NULL) {
		char *value;

		value = strchr(key, ':');
		if (value)
			*(value++) = '\0';

		if (strcmp(key, "loglevel") == 0 && value &&
		    isdigit(value[0]) && strlen(value) == 1) {
			c->level = clamp(value[0] - '0', LOGLEVEL_EMERG,
					 LOGLEVEL_DEBUG + 1);
			c->flags |= CON_LOGLEVEL;
			continue;
		}

		if (!seen_serial_opts && isdigit(key[0]) && !value) {
			seen_serial_opts = true;
			c->options = key;
			continue;
		}

		fprintf(stderr,
			"ignoring invalid console option: '%s%s%s'\n", key,
			value ? ":" : "", value ?: "");
	}
}

int main(int argc, char *argv[])
{
	struct console_cmdline con = { 0 };

	if (argc != 2)
		return EXIT_FAILURE;

	parse_console_cmdline_options(&con, argv[1]);
	printf("options: %s\n", con.options);
	printf("level: %d\n", con.level);
}

---

% make CFLAGS='-Wall -Wextra -Werror' loglevel
cc -Wall -Wextra -Werror    loglevel.c   -o loglevel
% ./loglevel 9600n8
options: 9600n8
level: 0
level set: 0
% ./loglevel 9600n8,loglevel:3
options: 9600n8
level: 3
level set: 1
% ./loglevel 9600n8,loglevel:123
ignoring invalid console option: 'loglevel:123'
options: 9600n8
level: 0
level set: 0
% ./loglevel 9600n8,loglevel:3,foo:bar
ignoring invalid console option: 'foo:bar'
options: 9600n8
level: 3
level set: 1
% ./loglevel 9600n8,loglevel
ignoring invalid console option: 'loglevel'
options: 9600n8
level: 0
level set: 0
% ./loglevel loglevel
ignoring invalid console option: 'loglevel'
options: (null)
level: 0
level set: 0
% ./loglevel loglevel:7
options: (null)
level: 7
level set: 1

---

Seems to work ok as far as I can tell, maybe I've misunderstood your concern?  
Or maybe your concern is just about the mmio/io case where the driver wants 
that as part of the options?

>I thought a lot how to do it a clean way. IMHO, it would be great to
>parse everything at a single place but it might require updating
>all drivers. I am not sure if it is worth it.
>
>So, I suggest to do it another way. We could implement a generic
>function to find in the new key[:value] format. It would check
>if the given option (key) exists and read the optional value.
>
>The optional value would allow to define another new options
>that would not need any value, e.g. "kthread" or "atomic" that
>might be used in the upcoming code that allows to offload
>console handling to kthreads.

This could also work, and avoids the current null pointer shoving. It also can 
make the ordering less strict, which seems like a good thing.

I will think about it some more. I'm curious about your comments on the above 
test still though.

Thanks a lot for the detailed review and ideas!

Chris

  reply	other threads:[~2022-09-05 14:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 17:48 [PATCH v3 0/2] printk: console: Per-console loglevels Chris Down
2022-07-20 17:48 ` [PATCH v3 1/2] printk: console: Create console= parser that supports named options Chris Down
2022-08-31 10:13   ` Petr Mladek
2022-09-05 14:43     ` Chris Down [this message]
2022-09-05 14:45       ` Chris Down
2022-09-22 15:17       ` Petr Mladek
2023-04-17 15:04     ` Chris Down
2023-04-17 15:08       ` Chris Down
2023-04-18 13:43         ` Petr Mladek
2023-04-18 13:41       ` Petr Mladek
2023-04-19  0:31         ` Chris Down
2022-07-20 17:48 ` [PATCH v3 2/2] printk: console: Support console-specific loglevels Chris Down
2022-07-21  9:50   ` kernel test robot
2022-07-21 16:20     ` Chris Down
2022-07-21 16:16   ` kernel test robot
2022-07-21 16:29     ` Chris Down
2022-09-01  9:35   ` Petr Mladek
2022-09-05 14:07     ` Chris Down
2022-09-05 15:12       ` Petr Mladek
2022-07-20 18:22 ` [PATCH v3 0/2] printk: console: Per-console loglevels John Ogness
2022-07-20 18:29   ` Chris Down

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=YxYLKU8TWZ4T5ONF@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox