Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp5430734ybl; Tue, 27 Aug 2019 04:42:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqwxNEkEuMHrODry1xLPuC4x7MRD5aQov3WT7GONv/B8/IcAkYm3tp7BDKR3uLLDKfqAsP/V X-Received: by 2002:a17:90a:fa0a:: with SMTP id cm10mr23173966pjb.133.1566906143118; Tue, 27 Aug 2019 04:42:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566906143; cv=none; d=google.com; s=arc-20160816; b=ePwafJdiIkypY/dUexLpeqKs++whqkC0SCiKqdmIkfxSMOtuTpfR03UWdxrp4moi9d nvRU+TPcYoKlYgYenyMucdDRRdA3LWHvzgSxXHBIAYV0RwSwK4jVS1jrbwRqxsCWl/5a LgdNLFm4jQG+41Ge4DJKUAy0Yp1AGVCMnG7uHyn6rDQQEIEtnrmdoyy17575p+x3JYSR xul2EI3fNR3lne2Loonu63aW/sm/JvXl2TbUmDP1ocEalKeN65EZk7OjYUT1b6IW5sOm /wjoT41gvy8am98290/iHI2Mm4QU37TocI4qGQ8UNEt5moLOvD0ajA5m3x/+VyGZ3aHW Iu1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=+xFBxy6vB678vdjoJrTsnRBgg1NH6vA+vA1tUuzcfaE=; b=NmDrzgJOqbYjxp21GRxOlDa4UoxUDVWHhhWd0NLPfGnmra51Izha+4uAIGdD/rIHHc mUmdydMERk6j1cBQ1jpcxA4XkRSI3m5Ajje9IIoFcbsq+7gXDpBpXppDUjRBKCjvDHPQ DiHjNbgBS8jW2OYQ+ptKKC/3Lh/MFJafN2Oup7DHZuCo2B3Hh/03CkFitWJtnoVikZlm MYwiz6zhW0DubRa8bwPgpL5dx/DvFQRPw+Yz4wclH6mEwGwwi2cLas0LQ9bnjR/DY1+j q3BQdOC8yO3AXCgr9Je+96OznBz84PphOwwI1ZouYXNsX6QQjYmDZmj6b7OkukhMRQja wAAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n21si2334381pjt.33.2019.08.27.04.42.07; Tue, 27 Aug 2019 04:42:23 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727910AbfH0LlV (ORCPT + 99 others); Tue, 27 Aug 2019 07:41:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65064 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725912AbfH0LlV (ORCPT ); Tue, 27 Aug 2019 07:41:21 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AB59461D25; Tue, 27 Aug 2019 11:41:20 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id D2EEB600D1; Tue, 27 Aug 2019 11:41:16 +0000 (UTC) Date: Tue, 27 Aug 2019 13:41:14 +0200 From: Cornelia Huck To: Parav Pandit Cc: "alex.williamson@redhat.com" , Jiri Pirko , "kwankhede@nvidia.com" , "davem@davemloft.net" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" Subject: Re: [PATCH 1/4] mdev: Introduce sha1 based mdev alias Message-ID: <20190827134114.01ddd049.cohuck@redhat.com> In-Reply-To: References: <20190826204119.54386-1-parav@mellanox.com> <20190826204119.54386-2-parav@mellanox.com> <20190827122428.37442fe1.cohuck@redhat.com> <20190827132404.483a74ad.cohuck@redhat.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 27 Aug 2019 11:41:20 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Aug 2019 11:33:54 +0000 Parav Pandit wrote: > > -----Original Message----- > > From: Cornelia Huck > > Sent: Tuesday, August 27, 2019 4:54 PM > > To: Parav Pandit > > Cc: alex.williamson@redhat.com; Jiri Pirko ; > > kwankhede@nvidia.com; davem@davemloft.net; kvm@vger.kernel.org; linux- > > kernel@vger.kernel.org; netdev@vger.kernel.org > > Subject: Re: [PATCH 1/4] mdev: Introduce sha1 based mdev alias > > > > On Tue, 27 Aug 2019 11:12:23 +0000 > > Parav Pandit wrote: > > > > > > -----Original Message----- > > > > From: Cornelia Huck > > > > Sent: Tuesday, August 27, 2019 3:54 PM > > > > To: Parav Pandit > > > > Cc: alex.williamson@redhat.com; Jiri Pirko ; > > > > kwankhede@nvidia.com; davem@davemloft.net; kvm@vger.kernel.org; > > > > linux- kernel@vger.kernel.org; netdev@vger.kernel.org > > > > Subject: Re: [PATCH 1/4] mdev: Introduce sha1 based mdev alias > > > > > > > > What about: > > > > > > > > * @get_alias_length: optional callback to specify length of the alias to > > create > > > > * Returns unsigned integer: length of the alias to be created, > > > > * 0 to not create an alias > > > > > > > Ack. > > > > > > > I also think it might be beneficial to add a device parameter here > > > > now (rather than later); that seems to be something that makes sense. > > > > > > > Without showing the use, it shouldn't be added. > > > > It just feels like an omission: Why should the vendor driver only be able to > > return one value here, without knowing which device it is for? > > If a driver supports different devices, it may have different requirements for > > them. > > > Sure. Lets first have this requirement to add it. > I am against adding this length field itself without an actual vendor use case, which is adding some complexity in code today. > But it was ok to have length field instead of bool. > > Lets not further add "no-requirement futuristic knobs" which hasn't shown its need yet. > When a vendor driver needs it, there is nothing prevents such addition. Frankly, I do not see how it adds complexity; the other callbacks have device arguments already, and the vendor driver is free to ignore it if it does not have a use for it. I'd rather add the argument before a possible future user tries weird hacks to allow multiple values, but I'll leave the decision to the maintainers.