From: Kroah-Hartman <gregkh@linuxfoundation.org>
To: Calvin Owens <calvinowens@fb.com>
Cc: Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-api@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 2/3] printk: Add /sys/consoles/ interface
Date: Thu, 9 Nov 2017 09:03:21 +0100 [thread overview]
Message-ID: <20171109080321.GB17098@kroah.com> (raw)
In-Reply-To: <519f471b-47dc-3367-f702-119a9d82ba9b@fb.com>
On Wed, Nov 08, 2017 at 01:32:53PM -0800, Calvin Owens wrote:
> On 11/03/2017 07:32 AM, Kroah-Hartman wrote:
> > On Fri, Nov 03, 2017 at 03:21:14PM +0100, Petr Mladek wrote:
> > > On Thu 2017-09-28 17:43:56, Calvin Owens wrote:
> > > > This adds a new sysfs interface that contains a directory for each
> > > > console registered on the system. Each directory contains a single
> > > > "loglevel" file for reading and setting the per-console loglevel.
> > > >
> > > > We can let kobject destruction race with console removal: if it does,
> > > > loglevel_{show,store}() will safely fail with -ENODEV. This is a little
> > > > weird, but avoids embedding the kobject and therefore needing to totally
> > > > refactor the way we handle console struct lifetime.
> > >
> > > It looks like a sane approach. It might be worth a comment in the code.
> > >
> > >
> > > > Documentation/ABI/testing/sysfs-consoles | 13 +++++
> > > > include/linux/console.h | 1 +
> > > > kernel/printk/printk.c | 88 ++++++++++++++++++++++++++++++++
> > > > 3 files changed, 102 insertions(+)
> > > > create mode 100644 Documentation/ABI/testing/sysfs-consoles
> > > >
> > > > diff --git a/Documentation/ABI/testing/sysfs-consoles b/Documentation/ABI/testing/sysfs-consoles
> > > > new file mode 100644
> > > > index 0000000..6a1593e
> > > > --- /dev/null
> > > > +++ b/Documentation/ABI/testing/sysfs-consoles
> > > > @@ -0,0 +1,13 @@
> > > > +What: /sys/consoles/
> >
> > Eeek, what!
> >
> > > I rather add Greg in CC. I am not 100% sure that the top level
> > > directory is the right thing to do.
> >
> > Neither do I.
>
> Sure. This is a placeholder I choose arbitrarily pending some real input on
> the location, sorry I didn't make that clear.
>
> > > Alternative might be to hide this under /sys/kernel/consoles/.
> >
> > No no no.
> >
> > > > +Date: September 2017
> > > > +KernelVersion: 4.15
> > > > +Contact: Calvin Owens <calvinowens@fb.com>
> > > > +Description: The /sys/consoles tree contains a directory for each console
> > > > + configured on the system. These directories contain the
> > > > + following attributes:
> > > > +
> > > > + * "loglevel" Set the per-console loglevel: the kernel uses
> > > > + max(system_loglevel, perconsole_loglevel) when
> > > > + deciding whether to emit a given message. The
> > > > + default is 0, which means max() always yields
> > > > + the system setting in the kernel.printk sysctl.
> > >
> > > I would call the attribute "min_loglevel". The name "loglevel" should
> > > be reserved for the really used loglevel that depends also on the
> > > global loglevel value.
> > >
> > >
> > > > diff --git a/include/linux/console.h b/include/linux/console.h
> > > > index a5b5d79..76840be 100644
> > > > --- a/include/linux/console.h
> > > > +++ b/include/linux/console.h
> > > > @@ -148,6 +148,7 @@ struct console {
> > > > void *data;
> > > > struct console *next;
> > > > int level;
> > > > + struct kobject *kobj;
> >
> > Why are you using "raw" kobjects and not a "real" struct device? This
> > is a device, use that interface instead please.
> >
> > If you need a console 'bus' to place them on, fine, but the virtual bus
> > is probably best and simpler to use.
>
> The problem is that the console corresponds to no actual device (this is what
> Petr was getting at in the other mail). A console *may* be associated with a real
> TTY device, but this isn't universally true (for example, see netconsole_ext).
>
> Embedding a device struct in the console structure is problematic for the same
> reason embedding a raw kobject is: we'd need to rewrite all the code to deal with
> the new refcount/release semantics.
That's ok, that is what you _should_ do :)
> While that's certainly possible, it ends up being a much bigger thorny change. If
> we deal with the "get()/deregister()" race in a safe way, it becomes very simple.
>
> (If it were as trivial as replacing kfrees with puts and adding release callbacks,
> that'd be the obvious way to go, but of course it doesn't end up being that nice...)
I agree it's not trivial, but it's the correct change here, don't try to
abuse the driver core / kobjects, they will come back to bite you :)
> > That is if you _really_ feel you need sysfs interaction with the console
> > layer (hint, I am not yet convinced...)
>
> How would you expose this setting if not via sysfs? All I care about is having the
> setting, how exactly userspace pokes it is not at all important :)
A per-console log-level? I don't know, how do per-console settings work
today, ioctls?
"Fixing" consoles properly would be great work to undertake...
thanks,
greg k-h
next prev parent reply other threads:[~2017-11-09 8:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-29 0:43 [PATCH 1/3] printk: Introduce per-console loglevel setting Calvin Owens
2017-09-29 0:43 ` [PATCH 2/3] printk: Add /sys/consoles/ interface Calvin Owens
2017-11-03 14:21 ` Petr Mladek
2017-11-03 14:32 ` Kroah-Hartman
2017-11-03 15:46 ` Petr Mladek
2017-11-03 15:58 ` Kroah-Hartman
2017-11-08 21:32 ` Calvin Owens
2017-11-09 8:03 ` Kroah-Hartman [this message]
2017-09-29 0:43 ` [PATCH 3/3] printk: Add ability to set loglevel via "console=" cmdline Calvin Owens
2017-11-03 15:15 ` Petr Mladek
2017-10-19 23:40 ` [PATCH 1/3] printk: Introduce per-console loglevel setting Calvin Owens
2017-10-20 8:05 ` Petr Mladek
2017-10-20 17:33 ` Calvin Owens
2017-11-03 12:00 ` Petr Mladek
2017-11-03 13:41 ` Steven Rostedt
2018-10-19 0:04 ` Sergey Senozhatsky
2018-10-19 22:03 ` Calvin Owens
2018-10-22 2:37 ` Sergey Senozhatsky
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=20171109080321.GB17098@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=calvinowens@fb.com \
--cc=kernel-team@fb.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--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).