mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Peter Rajnoha <prajnoha@redhat.com>
Cc: linux-kernel@vger.kernel.org, msekleta@redhat.com
Subject: Re: [PATCH v2] kobject: add kernel/uevent_features sysfs file
Date: Fri, 7 Dec 2018 13:01:23 +0100	[thread overview]
Message-ID: <20181207120123.GB15336@kroah.com> (raw)
In-Reply-To: <20181207114607.26981-1-prajnoha@redhat.com>

On Fri, Dec 07, 2018 at 12:46:07PM +0100, Peter Rajnoha wrote:
> We can use extended format when writing /sys/.../uevent files to
> generate synthetic uevents, introduced with commit f36776fafbaa
> ("kobject: support passing in variables for synthetic uevents").
> 
> Before using this extended format, we need to know if it's supported
> and kernel version check may not be appropriate in all cases - there
> are possible differences from upstream kernel in distributions with
> backports.
> 
> This patch adds /sys/kernel/uevent_features file which currently lists
> 'synthargs' string to denote that the kernel is able to recognize the
> extended synthetic uevent arguments. Userspace can easily check for
> the feature then.

So this is just to try to have userspace detect what type of feature the
kernel has?  Why can't you just go off of the other sysfs file itself?
You shouldn't need a "this is a feature list" for the kernel, otherwise
we would be on a huge slippery slope trying to document everything.

Who is going to use this thing?  And what else would go into it?

Isn't there some other way you can detect this from userspace (like
writing to the file and it fails?)

thanks,

greg k-h

  reply	other threads:[~2018-12-07 12:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07 11:46 Peter Rajnoha
2018-12-07 12:01 ` Greg KH [this message]
2018-12-07 12:28   ` Peter Rajnoha
2018-12-19  9:24     ` Greg KH
2019-01-02  9:59       ` Peter Rajnoha
2019-01-08 14:23         ` Greg KH

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=20181207120123.GB15336@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msekleta@redhat.com \
    --cc=prajnoha@redhat.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

Powered by JetHome