Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 7 Dec 2018 13:01:23 +0100
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
Message-ID: <20181207120123.GB15336@kroah.com>
References: <20181207114607.26981-1-prajnoha@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181207114607.26981-1-prajnoha@redhat.com>
User-Agent: Mutt/1.11.1 (2018-12-01)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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