linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Chris Down <chris@chrisdown.name>,
	linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	John Ogness <john.ogness@linutronix.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	kernel-team@fb.com, Alexey Dobriyan <adobriyan@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jason Baron <jbaron@akamai.com>,
	Kees Cook <keescook@chromium.org>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH] printk: Userspace format enumeration support
Date: Fri, 5 Feb 2021 12:47:48 -0500	[thread overview]
Message-ID: <20210205124748.4af2d406@gandalf.local.home> (raw)
In-Reply-To: <YB11jybvFCb95S9e@alley>

On Fri, 5 Feb 2021 17:42:55 +0100
Petr Mladek <pmladek@suse.com> wrote:

> Hi,
> 
> I would like to hear opinion from a bigger audience. It is an
> userspace interface that we might need to maintain forewer.
> Adding few more people in to CC:
> 
> Steven Rostedt <rostedt@goodmis.org>: printk co-maintainer

Thanks for Cc'ing me.

> Alexey Dobriyan <adobriyan@gmail.com>: fs/proc maintainer
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>: sysfs maintainer
> Jason Baron <jbaron@akamai.com>: dynamic_debug maintainer
> Kees Cook <keescook@chromium.org>: security POV
> linux-api@vger.kernel.org: Linux API mailing list
> 
> Of course, we should also ask if this is the right approach
> for the think that you want to achieve.
> 
> The motivation for this patch is that the strings printed by kernels
> are not reliable and you want a simple way to compare differences
> bethween versions. Do I get it right?
> 
> See more comments below.
> 
> 


> Also this is yet another style how the format is displayed. We already have
> 
> 	+ console/syslog: formated by record_print_text()
> 	+ /dev/kmsg: formatted by info_print_ext_header(),  msg_print_ext_body().
> 	+ /sys/kernel/debug/dynamic_debug/control


> 	+ /sys/kernel/debug/tracing/printk_formats
> 
> We should get some inspiration from the existing interfaces.

Interesting, because when I was looking at the original patch (looked at
the lore link before reading your reply), I thought to myself "this looks
exactly like what I did for trace_printk formats", which the above file is
where it is shown. I'm curious if this work was inspired by that?



> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index 34b7e0d2346c..0ca6e28e05d6 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -309,6 +309,17 @@
> >  #define ACPI_PROBE_TABLE(name)
> >  #endif
> >  
> > +#ifdef CONFIG_PRINTK_ENUMERATION
> > +#define PRINTK_FMTS							\
> > +	.printk_fmts : AT(ADDR(.printk_fmts) - LOAD_OFFSET) {		\
> > +		__start_printk_fmts = .;				\
> > +		*(.printk_fmts)						\
> > +		__stop_printk_fmts = .;					\
> > +	}
> > +#else
> > +#define PRINTK_FMTS
> > +#endif  
> 
> It should be defined after #define TRACEDATA to follow the existing
> style.
> 
> But honestly I am not much familiar with the sections definitions.
> I am curious why TRACE_PRINTKS() and __dyndbg are defined
> a bit different way.
> 

I'm not sure what difference you mean.

> > +static int proc_pf_show(struct seq_file *s, void *v)
> > +{
> > +	const struct printk_fmt_sec *ps = NULL;
> > +	const char **fptr = NULL;
> > +
> > +	mutex_lock(&printk_fmts_mutex);
> > +
> > +	list_for_each_entry(ps, &printk_fmts_list, list) {
> > +		const char *mod_name = ps_get_module_name(ps);
> > +
> > +		for (fptr = ps->start; fptr < ps->end; fptr++) {
> > +			seq_puts(s, mod_name);
> > +			seq_putc(s, ',');
> > +			seq_puts(s, *fptr);
> > +			seq_putc(s, '\0');
> > +		}  
> 
> You probably should get inspiration from t_show() in trace_printk.c.
> It handles newlines, ...
> 
> Or by ddebug_proc_show(). It uses seq_escape().
> 
> Anyway, there is something wrong at the moment. The output looks fine
> with cat. But "less" says that it is a binary format and the output
> is a bit messy:

Hmm, that's usually the case when lseek gets messed up. Not sure how that
happened.

> 
> $> less /proc/printk_formats   
> "/proc/printk_formats" may be a binary file.  See it anyway? 
> vmlinux,^A3Warning: unable to open an initial console.
> ^@vmlinux,^A3Failed to execute %s (error %d)
> ^@vmlinux,^A6Kernel memory protection disabled.
> ^@vmlinux,^A3Starting init: %s exists but couldn't execute it (error %d)
> 
> 
> That is for now. I still have to think about it. And I am also curious
> about what others thing about this idea.
> 

I'm not against the idea. I don't think it belongs in /proc. Perhaps
debugfs is a better place to put it.

-- Steve

  reply	other threads:[~2021-02-05 17:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YBwU0G+P0vb9wTwm@chrisdown.name>
2021-02-05 16:42 ` [PATCH] printk: Userspace format enumeration support Petr Mladek
2021-02-05 17:47   ` Steven Rostedt [this message]
2021-02-05 22:45     ` Chris Down
2021-02-05 22:49       ` Steven Rostedt
2021-02-06  7:13       ` Greg Kroah-Hartman
2021-02-06 12:44         ` Chris Down
2021-02-05 22:25   ` Chris Down
2021-02-06 17:57     ` Joe Perches
2021-02-06 21:21       ` Chris Down
2021-02-07  4:41         ` Joe Perches
2021-02-07 14:13           ` Chris Down
2021-02-07 14:58             ` Joe Perches
2021-02-07 16:13               ` Chris Down
2021-02-07 16:53                 ` 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=20210205124748.4af2d406@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chrisdown.name \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=jbaron@akamai.com \
    --cc=john.ogness@linutronix.de \
    --cc=keescook@chromium.org \
    --cc=kernel-team@fb.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=sergey.senozhatsky@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).