From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D2ABC07E85 for ; Fri, 7 Dec 2018 12:28:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 52A7F20989 for ; Fri, 7 Dec 2018 12:28:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52A7F20989 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726066AbeLGM2z (ORCPT ); Fri, 7 Dec 2018 07:28:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52948 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbeLGM2y (ORCPT ); Fri, 7 Dec 2018 07:28:54 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 909DD30024A2; Fri, 7 Dec 2018 12:28:54 +0000 (UTC) Received: from alatyr.usersys.redhat.com (unknown [10.43.17.162]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D86966293B; Fri, 7 Dec 2018 12:28:53 +0000 (UTC) Subject: Re: [PATCH v2] kobject: add kernel/uevent_features sysfs file To: Greg KH Cc: linux-kernel@vger.kernel.org, msekleta@redhat.com References: <20181207114607.26981-1-prajnoha@redhat.com> <20181207120123.GB15336@kroah.com> From: Peter Rajnoha Message-ID: Date: Fri, 7 Dec 2018 13:28:52 +0100 MIME-Version: 1.0 In-Reply-To: <20181207120123.GB15336@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Fri, 07 Dec 2018 12:28:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/7/18 1:01 PM, Greg KH wrote: > On Fri, Dec 07, 2018 at 12:46:07PM +0100, Peter Rajnoha wrote: >> 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?) > Yes, it's for userspace to be sure that uevent interface has certain features available that it can use. For now, it's just that "synthetic uevent arguments" that is the extension of the original uevent interface. That applies to both input (writing to /sys/.../uevent file) and output (related extra variables that appear in generated uevents). The obvious user of this is going to be systemd/udev that will add extra variables to identify various synthetic uevents it produces (coming as result of the WATCH udev rule, coming from the udevadm trigger call and other specific uses where it needs to generate synthetic uevents). Other users I know of involve storage handling tools which need to generate these synthetic uevents whenever a change happens and it needs to synchronize with udevd processing (e.g. waiting on refresh to get reflected in udev database). I understand that there is an argument that we can just use kernel version check, but this is not acceptable for all unfortunately (see also https://github.com/systemd/systemd/pull/7294#issuecomment-343491015). The issue with checking the return code after writing to /sys/.../uevent is that it doesn't work with older kernel releases because there, it always returned success, no matter if the input string was correct or not or whether the arguments were recognized (unfortunately, this was like that from beginning, it seems). Even though, I've fixed this return code with df44b479 recently, but still, there are possible older releases out there... And still, there might be new variables introduced in the future that don't necessarily need to be direct result of writing to /sys/.../uevent file. -- Peter