The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH printk 17/18] printk: Use an output descriptor struct for emit
Date: Mon, 10 Oct 2022 17:40:13 +0200	[thread overview]
Message-ID: <Y0Q83TZnQcCF/mDi@alley> (raw)
In-Reply-To: <20220924000454.3319186-18-john.ogness@linutronix.de>

On Sat 2022-09-24 02:10:53, John Ogness wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> To prepare for a new console infrastructure that is independent of the
> console BKL, wrap the output mode into a descriptor struct so the new
> infrastrucure can share the emit code that dumps the ringbuffer record
> into the output text buffers.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> ---
>  include/linux/console.h | 15 +++++++
>  kernel/printk/printk.c  | 88 ++++++++++++++++++++++++++++++-----------
>  2 files changed, 79 insertions(+), 24 deletions(-)
> 
> diff --git a/include/linux/console.h b/include/linux/console.h
> index 05c7325e98f9..590ab62c01d9 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -187,6 +187,21 @@ struct cons_text_buf {
>  	char		text[CONSOLE_LOG_MAX];
>  };
>  
> +/**
> + * struct cons_outbuf_desc - console output buffer descriptor
> + * @txtbuf:		Pointer to buffer for storing the text
> + * @outbuf:		Pointer to the position in @buffer for
> + *			writing it out to the device

This sounds like this pointer might point into the middle of
some buffer. It sounds scarry without providing the remaining
size of the buffer.

It seems that the pointer is actually used to point to
one of the buffers in txtbuf struct. Then it is again
a bit scarry without the size. I know that it is defined
by @len. But it is not obvious that it is related.

> + * @len:		Message length

It is not clear that it is length of the outbuf.

> + * @extmsg:		Select extended format printing

It would be nice to make it obvious (variable name)
that it is bool and not another buffer.

This actually defines which buffer will be used
in txtbuf.

> + */
> +struct cons_outbuf_desc {
> +	struct cons_text_buf	*txtbuf;
> +	char			*outbuf;
> +	unsigned int		len;
> +	bool			extmsg;
> +};

Sigh, I somehow do not like this structure. I think that the main
problem is that it combines both input and output values.

Also there is too much assignments here and there.

What about?

1. Storing "struct cons_text_buf *txtbuf" into struct console.
   Normal consoles might point to a global txtbuf.
   Atomic consoles might point to the allocated ones.

2. Create structure for writing the next record
   on the console, for example:

   struct console_record {	/* like struct printk_record */
	char *buf;
	int size;
	int len;
   }

Then we could implement:

bool console_get_record(struct console *con,
			struct console_record *cr)
{
	struct cons_text_buf *txtbuf = con->txtbuf;
	struct printk_info info;
	struct printk_record r;
	char *write_text;
	size_t len;

	cr->buf = NULL;
	cr->size = 0;
	cr->len = 0;

	prb_rec_init_rd(&r, &info, txtbuf->text, sizeof(txtbuf->text);

	if (!prb_read_valid(prb, desc->seq, &r))
		return false;

	/* Skip record that has level above the console loglevel. */
	if (suppress_message_printing(r.info->level)) {
		return true;
	}

	if (con->flags & CON_EXTENDED) {
		cr->buf = txtbuf->ext_text;
		cr->size = sizeof(txtbuf->ext_text);
		info_print_ext_header(cr, r.info);
		msg_print_ext_body(cr, &r);
	} else {
		cr->buf = txtbuf->text;
		cr->size = sizeof(txtbuf->text);
		record_print_text(cr, &r, console_msg_format & MSG_FORMAT_SYSLOG, printk_time);

		cons_print_dropped(cr, con);
	}

	return true;
}

and

static bool console_emit_next_record(struct console *con,
				     bool *handover)
{
	struct console_record cr;
	unsigned long flags;

	*handover = false;

	if (!console_get_next_record(con, cr))
		return false;

	/* supressed? */
	if (!cr->buf) {
		con->seq++;
		return true;
	}

	/*
	 * While actively printing out messages, if another printk()
	 * were to occur on another CPU, it may wait for this one to
	 * finish. This task can not be preempted if there is a
	 * waiter waiting to take over.
	 *
	 * Interrupts are disabled because the hand over to a waiter
	 * must not be interrupted until the hand over is completed
	 * (@console_waiter is cleared).
	 */
	printk_safe_enter_irqsave(flags);
	console_lock_spinning_enable();

	/* don't trace print latency */
	stop_critical_timings();
	/* Write everything out to the hardware */
	con->write(con, cr->buf, cr->len);
	start_critical_timings();

	con->seq++;

	*handover = console_lock_spinning_disable_and_check();
	printk_safe_exit_irqrestore(flags);

	return true;
}

Advantages:

	+ even less parameters
	+ less assignments (read/write directly in struct console)
	+ struct console_record has just output buffer =>
	  no confusion about the names

How does that sound, please?

Best Regards,
Petr

  reply	other threads:[~2022-10-10 15:40 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-24  0:04 [PATCH printk 00/18] preparation for threaded/atomic printing John Ogness
2022-09-24  0:04 ` [PATCH printk 01/18] printk: Make pr_flush() static John Ogness
2022-09-26 14:12   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 02/18] printk: Declare log_wait properly John Ogness
2022-09-26 14:22   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 03/18] printk: Remove write only variable nr_ext_console_drivers John Ogness
2022-09-26 14:25   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 04/18] printk: Remove bogus comment vs. boot consoles John Ogness
2022-09-26 14:26   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 05/18] printk: Mark __printk percpu data ready __ro_after_init John Ogness
2022-09-26 14:27   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 06/18] printk: Protect [un]register_console() with a mutex John Ogness
2022-09-24  9:31   ` Sergey Senozhatsky
2022-09-27 15:16   ` Petr Mladek
2022-09-28  9:46     ` Sergey Senozhatsky
2022-09-28 23:42     ` John Ogness
2022-09-29 15:43       ` Petr Mladek
2022-09-30  9:24         ` Petr Mladek
2022-09-30 14:16           ` John Ogness
2022-09-30 18:04             ` Petr Mladek
2022-09-30 20:26               ` John Ogness
2022-10-03 14:37                 ` Petr Mladek
2022-10-03 19:35                   ` John Ogness
2022-10-04  2:06                     ` Sergey Senozhatsky
2022-10-04  7:28                     ` Petr Mladek
2022-09-30 13:30         ` John Ogness
2022-09-24  0:04 ` [PATCH printk 07/18] printk: Convert console list walks for readers to list lock John Ogness
2022-09-27 14:07   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 08/18] parisc: Put console abuse into one place John Ogness
2022-09-24  0:20   ` Steven Rostedt
2022-09-30  7:54   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 09/18] serial: kgdboc: Lock console list in probe function John Ogness
2022-09-28 23:32   ` Doug Anderson
2022-09-30  8:07   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 10/18] kgbd: Pretend that console list walk is safe John Ogness
2022-09-26  9:33   ` Aaron Tomlin
2022-09-28 23:32   ` Doug Anderson
2022-09-30  8:39     ` Petr Mladek
2022-09-30 13:44       ` John Ogness
2022-09-30 17:27         ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 11/18] printk: Convert console_drivers list to hlist John Ogness
2022-09-24 10:53   ` Sergey Senozhatsky
2022-09-24 17:20   ` Helge Deller
2022-09-25  0:43     ` Sergey Senozhatsky
2022-09-24 17:27   ` Helge Deller
2022-09-30 14:20   ` Petr Mladek
2022-09-30 16:53     ` Helge Deller
2022-09-30 19:46       ` John Ogness
2022-09-30 22:41         ` Helge Deller
2022-09-24  0:04 ` [PATCH printk 12/18] printk: Prepare for SCRU console list protection John Ogness
2022-09-24 10:58   ` Sergey Senozhatsky
2022-09-24  0:04 ` [PATCH printk 13/18] printk: Move buffer size defines John Ogness
2022-09-24 11:01   ` Sergey Senozhatsky
2022-10-07  9:11   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 14/18] printk: Document struct console John Ogness
2022-09-24 11:08   ` Sergey Senozhatsky
2022-10-07 11:57   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 15/18] printk: Add struct cons_text_buf John Ogness
2022-09-24 11:09   ` Sergey Senozhatsky
2022-10-07 15:15   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 16/18] printk: Use " John Ogness
2022-09-24 11:34   ` Sergey Senozhatsky
2022-10-10 10:11   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 17/18] printk: Use an output descriptor struct for emit John Ogness
2022-10-10 15:40   ` Petr Mladek [this message]
2022-09-24  0:04 ` [PATCH printk 18/18] printk: Handle dropped message smarter John Ogness
2022-09-26  4:19   ` Sergey Senozhatsky
2022-09-26  7:54     ` John Ogness
2022-09-26  9:18       ` Sergey Senozhatsky
2022-10-10 16:07       ` Petr Mladek
2022-09-26  9:22   ` Sergey Senozhatsky
2022-09-24  6:44 ` [PATCH printk 00/18] preparation for threaded/atomic printing Greg Kroah-Hartman
2022-09-25 15:23   ` John Ogness
2022-09-24  9:47 ` Sergey Senozhatsky
2022-09-29 16:33 ` Petr Mladek

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=Y0Q83TZnQcCF/mDi@alley \
    --to=pmladek@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tglx@linutronix.de \
    /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