Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1111996ybh; Mon, 13 Jul 2020 09:37:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydRQsiE4YxLWGdxzSqUdQCEEOJMr+9OQ8o3s8MWNniXi67QwHCguM3DQEIzSHPw2xl7Oq/ X-Received: by 2002:a17:906:1414:: with SMTP id p20mr532095ejc.247.1594658235009; Mon, 13 Jul 2020 09:37:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594658235; cv=none; d=google.com; s=arc-20160816; b=dQuxwSwsyWrK7B1fq12/kXrdx15PnUI7VTHFzfBkP+NfBgOG3a5y/qIdwgqZHOHBdr Dcs9hphJeG1JoKiwn2OfEkd/dJRCz/quZDBeSdLC7nVOQG3zWp4XR+1uxLlgzdmOAPKa lcvcw/9S937674RdfgSx0N+8lDDQht8ahOXo28+77EZchkYxpVMKaWqRUmyQsJNAcPpy BXV0wo5tsuDoIegNqLCTf6PFTaijBlSr34PzKDFrv2YGIRkmMvXsWapEfc8fvrLPDOH6 IFGFSXKMsoWnxtKxZbwcH2cqDNDOW+aUEtp0pRolch3awM3V+DGFFmC+DzyivCoyDUWi 9Cnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=JZNThefDeIHtE1ePtyRHJh2smc+ji3rHASWHkarQpEA=; b=w2FxljNNe4c06l97A13GbDTB1RTvzjk6E/ilQlD24XkCgPjmcsix+xM3pT179eZ+zO 3CmcWo1iJDHx4pudzRzISGhxi/0kauJMB4Kc1uluHhJn1FubMk/gG5YsSPTsZ6OYEhcQ jSR2xO1x23kAhpl3h0SRw9Vba865VlqMvJ9ImKIbgMN+SzT6lRyaHOFzBSyaI136dIwr dpJeDXg6fqajejRDwXmiqcG6YsC9JArJtaOjTyDcdmzrmHO8ue3lXgTkVCfvqDREhSjR XttU5E0SvAXFczZqM+xKYYa9GbmKPV+kEtHeOWWj+e+eN7DOONDt/xuVSq4s7wqCCOC7 ReRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="r/hwhToy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qx22si8762524ejb.148.2020.07.13.09.36.50; Mon, 13 Jul 2020 09:37:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="r/hwhToy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730752AbgGMQg1 (ORCPT + 99 others); Mon, 13 Jul 2020 12:36:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730748AbgGMQgZ (ORCPT ); Mon, 13 Jul 2020 12:36:25 -0400 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DEE7CC061794 for ; Mon, 13 Jul 2020 09:36:24 -0700 (PDT) Received: by mail-ej1-x641.google.com with SMTP id dr13so17958297ejc.3 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=XfSrfHrNX+TPJOhy0GDvjD1Ex+ZKBDNINweBg7m5Im3RrYOO3ABcdDU4FgQqyT58tq HwdGmMjDczIhBfJkb+sbKT5c+FuTOoxjh1m5SmdLp/Wz00FcATX6TudtXgQWIKT9Qf5I nviI8sCJVV4LhXALC3QeyKspmUqDkYl018DxJ3RjNQjyh4H7ylI2hHbzEPwokUSBv9s6 nxoXqVWm5GIBIU1RCbT1Xn5MjbAsNDaCObR4NEkANycE4HY2BRNXNW5Ovzin+vmxoKYN I8FmGozdRvTCnVj850QdaQglH20ffi3fmFEok7PN99Z8LacfXOsooLbJQ2gIOa3hb3S7 BLLw== X-Gm-Message-State: AOAM5315wERR7ju27+iWtBWlZUnFuxlzfmt8vkbUY1SlAQAqp8AiHg5/ +iWA43t/Gw+1mWYHnSWyfEb0ZP0k7YhuDI1KGHUUWg== 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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.