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=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 5F460C433FE for ; Mon, 13 Jul 2020 16:36:28 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2EB852067D for ; Mon, 13 Jul 2020 16:36:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="r/hwhToy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2EB852067D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id E301B11812916; Mon, 13 Jul 2020 09:36:27 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::644; helo=mail-ej1-x644.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6862011812911 for ; Mon, 13 Jul 2020 09:36:24 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id lx13so17943944ejb.4 for ; Mon, 13 Jul 2020 09:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZNThefDeIHtE1ePtyRHJh2smc+ji3rHASWHkarQpEA=; b=r/hwhToyzhzg5/h5ygCjJ458Jk5Wh/GLR4dkOAyc3nmzc2aqTLsx+s5BGZT3ir/OKo 6R5Idb53R3uplzvPZRn2E+M9eXKxf5rYFtoEC7Kp9PbrU7m5nGXYM1qOjK2axYP1oLEN /uwxZbEZ8DYFqpXi83o0hVwVI6GKb/UOJYS6dG1LEouBCigaLZIqRh7Cca2yae2srQ6G mEDPayiqI+EOuBE0CAJvoi6oH4U+hqK/GxHt9jARP65uekKzTDprCRWAxiLvTDLVsLQC ktmXIHRQjZGsB9vRUQzIB3AR2Y+L1vKF50uWQxV+zE15bZebpEJAWBQB3fmJ5nkjMpqx SsGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZNThefDeIHtE1ePtyRHJh2smc+ji3rHASWHkarQpEA=; b=FQyfnqbqKGSjJBopXCYi5CPIEs6bvbKyjqEoZsaR+y1TfJBYQAZpiQSoA93A+xJT8R 7+UMOCHTAf43R8lGsyhYCL/w8O1ybpfEmckGkWwW9Z+zUFqoQTre3cA8cCXjRj8mlvkL DkLRx2bY7MGS+IvGWrADtxzAn3G0+8ZdgQNRyDXAlvYgdjZawoTst6tSMutVgP812tuh wklc8vuDgxKrMUl/J2r38LkgBd+hKqHgH8YTmpNYxJHgWhP4hRKAAY6MSljV8qyLOWqH 7Rz8sT/eA1YlgT+z3nnPJCwqhNDukc9htaRgoYi5K2s0jRja1h63lvjqw62A4iM625eh wm/w== X-Gm-Message-State: AOAM533+HYBoGq8xe6dY/1sXRKhBFXe+Na4rb8NX/p4STa4Gu/Yhd6DY vuZomiWy6C3hCVS7SbXs0azB1RdaYvaZbEy7OWKjaA== X-Google-Smtp-Source: ABdhPJz7kJwN+FtUOtRMjCPxLqFf8n0GyUdgjTjIsPmDaKxiXHa/S9B+1Hu/3Wxq5ZlAvUmHgOkdeaVL/w0Di9GcUBo= X-Received: by 2002:a17:906:6d56:: with SMTP id a22mr588276ejt.440.1594658183401; Mon, 13 Jul 2020 09:36:23 -0700 (PDT) MIME-Version: 1.0 References: <159457116473.754248.7879464730875147365.stgit@dwillia2-desk3.amr.corp.intel.com> <159457125753.754248.6000936585361264069.stgit@dwillia2-desk3.amr.corp.intel.com> <20200712170945.GA194499@kroah.com> <20200713155222.GB267581@kroah.com> <20200713161251.GA366826@kroah.com> In-Reply-To: <20200713161251.GA366826@kroah.com> From: Dan Williams Date: Mon, 13 Jul 2020 09:36:12 -0700 Message-ID: Subject: Re: [PATCH v2 17/22] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs To: Greg Kroah-Hartman Message-ID-Hash: Q7OIWAEPENYUR6J6YKFBHNY23UOA2E6Q X-Message-ID-Hash: Q7OIWAEPENYUR6J6YKFBHNY23UOA2E6Q X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: linux-nvdimm , "Rafael J. Wysocki" , Peter Zijlstra , Dave Hansen , Ard Biesheuvel , Linux MM , Linux Kernel Mailing List , Linux ACPI , Christoph Hellwig , Joao Martins X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Jul 13, 2020 at 9:13 AM Greg Kroah-Hartman wrote: > > On Mon, Jul 13, 2020 at 09:09:18AM -0700, Dan Williams wrote: > > On Mon, Jul 13, 2020 at 8:52 AM Greg Kroah-Hartman > > wrote: > > > > > > On Mon, Jul 13, 2020 at 08:39:43AM -0700, Dan Williams wrote: > > > > On Sun, Jul 12, 2020 at 10:09 AM Greg Kroah-Hartman > > > > wrote: > > > > > > > > > > On Sun, Jul 12, 2020 at 09:27:37AM -0700, Dan Williams wrote: > > > > > > Use sysfs_streq() in device_find_child_by_name() to allow it to use a > > > > > > sysfs input string that might contain a trailing newline. > > > > > > > > > > > > The other "device by name" interfaces, > > > > > > {bus,driver,class}_find_device_by_name(), already account for sysfs > > > > > > strings. > > > > > > > > > > > > Cc: Greg Kroah-Hartman > > > > > > Cc: "Rafael J. Wysocki" > > > > > > Signed-off-by: Dan Williams > > > > > > --- > > > > > > drivers/base/core.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > > > > > index 67d39a90b45c..5d31b962c898 100644 > > > > > > --- a/drivers/base/core.c > > > > > > +++ b/drivers/base/core.c > > > > > > @@ -3078,7 +3078,7 @@ struct device *device_find_child_by_name(struct device *parent, > > > > > > > > > > > > klist_iter_init(&parent->p->klist_children, &i); > > > > > > while ((child = next_device(&i))) > > > > > > - if (!strcmp(dev_name(child), name) && get_device(child)) > > > > > > + if (sysfs_streq(dev_name(child), name) && get_device(child)) > > > > > > > > > > Who wants to call this function with a name passed from userspace? > > > > > > > > > > Not objecting to it, just curious... > > > > > > > > > > > > > The series that incorporates this patch adds a partitioning mechanism > > > > to "device-dax region" devices with an: > > > > "echo 1 > regionX/create" to create a new partition / sub-instance > > > > of a region, and... > > > > "echo $devname > regionX/delete" to delete. Where $devname is > > > > searched in the child devices of regionX to trigger device_del(). > > > > > > Shouldn't that be done in configfs, not sysfs? > > > > I see configfs as an awkward fit for this situation. configfs wants to > > software define kernel objects whereas this facility wants to augment > > existing kernel enumerated device objects. The region device is > > created by firmware policy and is optionally partitioned, configfs > > objects don't exist at all until created. So for this I see sysfs + > > 'scheme to trigger child device creation' as just enough mechanism > > that does not warrant full blown configfs. > > > > I believe it was debates like this [1] that have led me to the camp of > > sysfs being capable of some device creation dynamism and leave > > configfs for purely software constructed objects. > > > > [1]: https://lore.kernel.org/lkml/17377.42813.479466.690408@cse.unsw.edu.au/ > > "some" :) Yes, lowercase and quoted: "some" :). > And that was from 2006, ugh, how did you find that... Oh, public-inbox is a wonderful thing. "I kinda sort of remember Neil laying out a configfs vs sysfs argument", /me searches for "f:neil configfs" and voila. > Ok, that's fine, no objection from me for this patch: > > Reviewed-by: Greg Kroah-Hartman Thanks, Greg. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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=-10.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 482B3C433EA for ; Mon, 13 Jul 2020 16:36:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 25E5C20773 for ; Mon, 13 Jul 2020 16:36:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="r/hwhToy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730496AbgGMQgb (ORCPT ); Mon, 13 Jul 2020 12:36:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730747AbgGMQgZ (ORCPT ); Mon, 13 Jul 2020 12:36:25 -0400 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4737C061755 for ; Mon, 13 Jul 2020 09:36:24 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id o18so17930887eje.7 for ; Mon, 13 Jul 2020 09:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZNThefDeIHtE1ePtyRHJh2smc+ji3rHASWHkarQpEA=; b=r/hwhToyzhzg5/h5ygCjJ458Jk5Wh/GLR4dkOAyc3nmzc2aqTLsx+s5BGZT3ir/OKo 6R5Idb53R3uplzvPZRn2E+M9eXKxf5rYFtoEC7Kp9PbrU7m5nGXYM1qOjK2axYP1oLEN /uwxZbEZ8DYFqpXi83o0hVwVI6GKb/UOJYS6dG1LEouBCigaLZIqRh7Cca2yae2srQ6G mEDPayiqI+EOuBE0CAJvoi6oH4U+hqK/GxHt9jARP65uekKzTDprCRWAxiLvTDLVsLQC ktmXIHRQjZGsB9vRUQzIB3AR2Y+L1vKF50uWQxV+zE15bZebpEJAWBQB3fmJ5nkjMpqx SsGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZNThefDeIHtE1ePtyRHJh2smc+ji3rHASWHkarQpEA=; b=jS/nUE4zkzkCauPf3FS0WUEFuru8g4wBWAz3q1DOnAhRmun2vXf3zGpZ9iMkQ632nF +tF6Qi1nUyoOsgx3Tv37kqi1e0USMqOn6r3OgylHreTPJbcZfMRJGpwOvAPZHWjjHcnb sR+ANXA+galXZ4c1ckrHA67/XSw/CWi4bX6+VJ0t0FsbUqKfV+69ME89lqAliRTIs7oG Wbk4bhAkPnhKqBGxxp7UPUWfFje2mSePLGgG4stKmF2tkD1j5+ZdDbiW59JzkKC/kOgx 8SD7bX0RSyRJRnJfNV1GXdVnYM8pZM08zLt83Dl5Y0SHMjL9cq9ZBduSRTCAYJMKO1Jd nRfQ== X-Gm-Message-State: AOAM53062g7FV0q5yQpCuKcg5c37BfM1ELJ++xXbqc9KSxofbZeqk+Fa 2v5Uy1Z/nV5rEq1YUUTlLPcGl53Oy73I59YJeDrrQg== X-Google-Smtp-Source: ABdhPJz7kJwN+FtUOtRMjCPxLqFf8n0GyUdgjTjIsPmDaKxiXHa/S9B+1Hu/3Wxq5ZlAvUmHgOkdeaVL/w0Di9GcUBo= X-Received: by 2002:a17:906:6d56:: with SMTP id a22mr588276ejt.440.1594658183401; Mon, 13 Jul 2020 09:36:23 -0700 (PDT) MIME-Version: 1.0 References: <159457116473.754248.7879464730875147365.stgit@dwillia2-desk3.amr.corp.intel.com> <159457125753.754248.6000936585361264069.stgit@dwillia2-desk3.amr.corp.intel.com> <20200712170945.GA194499@kroah.com> <20200713155222.GB267581@kroah.com> <20200713161251.GA366826@kroah.com> In-Reply-To: <20200713161251.GA366826@kroah.com> From: Dan Williams Date: Mon, 13 Jul 2020 09:36:12 -0700 Message-ID: Subject: Re: [PATCH v2 17/22] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs To: Greg Kroah-Hartman Cc: linux-nvdimm , "Rafael J. Wysocki" , Peter Zijlstra , Vishal L Verma , Dave Hansen , Ard Biesheuvel , Linux MM , Linux Kernel Mailing List , Linux ACPI , Christoph Hellwig , Joao Martins Content-Type: text/plain; charset="UTF-8" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, Jul 13, 2020 at 9:13 AM Greg Kroah-Hartman wrote: > > On Mon, Jul 13, 2020 at 09:09:18AM -0700, Dan Williams wrote: > > On Mon, Jul 13, 2020 at 8:52 AM Greg Kroah-Hartman > > wrote: > > > > > > On Mon, Jul 13, 2020 at 08:39:43AM -0700, Dan Williams wrote: > > > > On Sun, Jul 12, 2020 at 10:09 AM Greg Kroah-Hartman > > > > wrote: > > > > > > > > > > On Sun, Jul 12, 2020 at 09:27:37AM -0700, Dan Williams wrote: > > > > > > Use sysfs_streq() in device_find_child_by_name() to allow it to use a > > > > > > sysfs input string that might contain a trailing newline. > > > > > > > > > > > > The other "device by name" interfaces, > > > > > > {bus,driver,class}_find_device_by_name(), already account for sysfs > > > > > > strings. > > > > > > > > > > > > Cc: Greg Kroah-Hartman > > > > > > Cc: "Rafael J. Wysocki" > > > > > > Signed-off-by: Dan Williams > > > > > > --- > > > > > > drivers/base/core.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > > > > > index 67d39a90b45c..5d31b962c898 100644 > > > > > > --- a/drivers/base/core.c > > > > > > +++ b/drivers/base/core.c > > > > > > @@ -3078,7 +3078,7 @@ struct device *device_find_child_by_name(struct device *parent, > > > > > > > > > > > > klist_iter_init(&parent->p->klist_children, &i); > > > > > > while ((child = next_device(&i))) > > > > > > - if (!strcmp(dev_name(child), name) && get_device(child)) > > > > > > + if (sysfs_streq(dev_name(child), name) && get_device(child)) > > > > > > > > > > Who wants to call this function with a name passed from userspace? > > > > > > > > > > Not objecting to it, just curious... > > > > > > > > > > > > > The series that incorporates this patch adds a partitioning mechanism > > > > to "device-dax region" devices with an: > > > > "echo 1 > regionX/create" to create a new partition / sub-instance > > > > of a region, and... > > > > "echo $devname > regionX/delete" to delete. Where $devname is > > > > searched in the child devices of regionX to trigger device_del(). > > > > > > Shouldn't that be done in configfs, not sysfs? > > > > I see configfs as an awkward fit for this situation. configfs wants to > > software define kernel objects whereas this facility wants to augment > > existing kernel enumerated device objects. The region device is > > created by firmware policy and is optionally partitioned, configfs > > objects don't exist at all until created. So for this I see sysfs + > > 'scheme to trigger child device creation' as just enough mechanism > > that does not warrant full blown configfs. > > > > I believe it was debates like this [1] that have led me to the camp of > > sysfs being capable of some device creation dynamism and leave > > configfs for purely software constructed objects. > > > > [1]: https://lore.kernel.org/lkml/17377.42813.479466.690408@cse.unsw.edu.au/ > > "some" :) Yes, lowercase and quoted: "some" :). > And that was from 2006, ugh, how did you find that... Oh, public-inbox is a wonderful thing. "I kinda sort of remember Neil laying out a configfs vs sysfs argument", /me searches for "f:neil configfs" and voila. > Ok, that's fine, no objection from me for this patch: > > Reviewed-by: Greg Kroah-Hartman Thanks, Greg. 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=-10.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 8203FC433F8 for ; Mon, 13 Jul 2020 16:36:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4865C2067D for ; Mon, 13 Jul 2020 16:36:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="r/hwhToy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4865C2067D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C2C198D0003; Mon, 13 Jul 2020 12:36:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB6998D0001; Mon, 13 Jul 2020 12:36:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7BB08D0003; Mon, 13 Jul 2020 12:36:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 8C7968D0001 for ; Mon, 13 Jul 2020 12:36:26 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 072CA8248047 for ; Mon, 13 Jul 2020 16:36:26 +0000 (UTC) X-FDA: 77033605572.30.fog31_4b158ec26ee9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id CBE97180B3C94 for ; Mon, 13 Jul 2020 16:36:25 +0000 (UTC) X-HE-Tag: fog31_4b158ec26ee9 X-Filterd-Recvd-Size: 7010 Received: from mail-ej1-f67.google.com (mail-ej1-f67.google.com [209.85.218.67]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 13 Jul 2020 16:36:24 +0000 (UTC) Received: by mail-ej1-f67.google.com with SMTP id y10so17967418eje.1 for ; Mon, 13 Jul 2020 09:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZNThefDeIHtE1ePtyRHJh2smc+ji3rHASWHkarQpEA=; b=r/hwhToyzhzg5/h5ygCjJ458Jk5Wh/GLR4dkOAyc3nmzc2aqTLsx+s5BGZT3ir/OKo 6R5Idb53R3uplzvPZRn2E+M9eXKxf5rYFtoEC7Kp9PbrU7m5nGXYM1qOjK2axYP1oLEN /uwxZbEZ8DYFqpXi83o0hVwVI6GKb/UOJYS6dG1LEouBCigaLZIqRh7Cca2yae2srQ6G mEDPayiqI+EOuBE0CAJvoi6oH4U+hqK/GxHt9jARP65uekKzTDprCRWAxiLvTDLVsLQC ktmXIHRQjZGsB9vRUQzIB3AR2Y+L1vKF50uWQxV+zE15bZebpEJAWBQB3fmJ5nkjMpqx SsGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZNThefDeIHtE1ePtyRHJh2smc+ji3rHASWHkarQpEA=; b=WJx0NDb8MHIIdkEMKv3ExqjIHQINH3BP0QqmtMl5FU0WGQKyxm+yIB04XcgCqsa+Vv h/+NW71fCzTYuVGG8fQr5o9rcyeh1XvFxUX+WDhCxO/8U1VPD3xZLTPIbw0IImm+uoPF 4LSH74KLeZVmvi+JNYyJgvRM8tjQijtB6v9wwykGFAFsmoNNHwKxKDDxr8WHj7p1KihJ Y+7eyESaJR4wcZ37eNBix7Z1KlZc3swqVw4Mj3C975I/XloknKc2Qo3kyjClA1ur46L5 dF48UcedmWEpgn7lLZIG+SylLfg+D25rhkvMSTVSmyWeEW5DcRfWw04iuU/7sWZXcnhL aVEQ== X-Gm-Message-State: AOAM533SvUdqBQ00njuMiadv3aadX2+dvK0XMJob1xremMZbIz9rGDf5 d3g9cNfcdrF/r6R1TANR3UVKJWlt2tv2ngD9sUJ13A== X-Google-Smtp-Source: ABdhPJz7kJwN+FtUOtRMjCPxLqFf8n0GyUdgjTjIsPmDaKxiXHa/S9B+1Hu/3Wxq5ZlAvUmHgOkdeaVL/w0Di9GcUBo= X-Received: by 2002:a17:906:6d56:: with SMTP id a22mr588276ejt.440.1594658183401; Mon, 13 Jul 2020 09:36:23 -0700 (PDT) MIME-Version: 1.0 References: <159457116473.754248.7879464730875147365.stgit@dwillia2-desk3.amr.corp.intel.com> <159457125753.754248.6000936585361264069.stgit@dwillia2-desk3.amr.corp.intel.com> <20200712170945.GA194499@kroah.com> <20200713155222.GB267581@kroah.com> <20200713161251.GA366826@kroah.com> In-Reply-To: <20200713161251.GA366826@kroah.com> From: Dan Williams Date: Mon, 13 Jul 2020 09:36:12 -0700 Message-ID: Subject: Re: [PATCH v2 17/22] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs To: Greg Kroah-Hartman Cc: linux-nvdimm , "Rafael J. Wysocki" , Peter Zijlstra , Vishal L Verma , Dave Hansen , Ard Biesheuvel , Linux MM , Linux Kernel Mailing List , Linux ACPI , Christoph Hellwig , Joao Martins Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: CBE97180B3C94 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jul 13, 2020 at 9:13 AM Greg Kroah-Hartman wrote: > > On Mon, Jul 13, 2020 at 09:09:18AM -0700, Dan Williams wrote: > > On Mon, Jul 13, 2020 at 8:52 AM Greg Kroah-Hartman > > wrote: > > > > > > On Mon, Jul 13, 2020 at 08:39:43AM -0700, Dan Williams wrote: > > > > On Sun, Jul 12, 2020 at 10:09 AM Greg Kroah-Hartman > > > > wrote: > > > > > > > > > > On Sun, Jul 12, 2020 at 09:27:37AM -0700, Dan Williams wrote: > > > > > > Use sysfs_streq() in device_find_child_by_name() to allow it to use a > > > > > > sysfs input string that might contain a trailing newline. > > > > > > > > > > > > The other "device by name" interfaces, > > > > > > {bus,driver,class}_find_device_by_name(), already account for sysfs > > > > > > strings. > > > > > > > > > > > > Cc: Greg Kroah-Hartman > > > > > > Cc: "Rafael J. Wysocki" > > > > > > Signed-off-by: Dan Williams > > > > > > --- > > > > > > drivers/base/core.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > > > > > index 67d39a90b45c..5d31b962c898 100644 > > > > > > --- a/drivers/base/core.c > > > > > > +++ b/drivers/base/core.c > > > > > > @@ -3078,7 +3078,7 @@ struct device *device_find_child_by_name(struct device *parent, > > > > > > > > > > > > klist_iter_init(&parent->p->klist_children, &i); > > > > > > while ((child = next_device(&i))) > > > > > > - if (!strcmp(dev_name(child), name) && get_device(child)) > > > > > > + if (sysfs_streq(dev_name(child), name) && get_device(child)) > > > > > > > > > > Who wants to call this function with a name passed from userspace? > > > > > > > > > > Not objecting to it, just curious... > > > > > > > > > > > > > The series that incorporates this patch adds a partitioning mechanism > > > > to "device-dax region" devices with an: > > > > "echo 1 > regionX/create" to create a new partition / sub-instance > > > > of a region, and... > > > > "echo $devname > regionX/delete" to delete. Where $devname is > > > > searched in the child devices of regionX to trigger device_del(). > > > > > > Shouldn't that be done in configfs, not sysfs? > > > > I see configfs as an awkward fit for this situation. configfs wants to > > software define kernel objects whereas this facility wants to augment > > existing kernel enumerated device objects. The region device is > > created by firmware policy and is optionally partitioned, configfs > > objects don't exist at all until created. So for this I see sysfs + > > 'scheme to trigger child device creation' as just enough mechanism > > that does not warrant full blown configfs. > > > > I believe it was debates like this [1] that have led me to the camp of > > sysfs being capable of some device creation dynamism and leave > > configfs for purely software constructed objects. > > > > [1]: https://lore.kernel.org/lkml/17377.42813.479466.690408@cse.unsw.edu.au/ > > "some" :) Yes, lowercase and quoted: "some" :). > And that was from 2006, ugh, how did you find that... Oh, public-inbox is a wonderful thing. "I kinda sort of remember Neil laying out a configfs vs sysfs argument", /me searches for "f:neil configfs" and voila. > Ok, that's fine, no objection from me for this patch: > > Reviewed-by: Greg Kroah-Hartman Thanks, Greg.