Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp5413296ybl; Tue, 27 Aug 2019 04:25:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqwnzdpPqKh09w+OLJ+sybFdvBowEdm54JJWJyjUvttNWLrUlgByxsjTrCOkddUYn2ZsiBGW X-Received: by 2002:a17:902:860b:: with SMTP id f11mr23570890plo.48.1566905118668; Tue, 27 Aug 2019 04:25:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566905118; cv=none; d=google.com; s=arc-20160816; b=ud5M8xQa7WUONpHIc5qUwELoTSGY0iMx5hnURNi2YPGXZ6Paz0hdlJIbnIos6fJhuQ ofTenimmJqEtIGAdKsypQQF7jnkEd2Y2s+z5GmtHaUQYBYzidKEtZVhcfbe8Cz/h2jAG lI/4UhVSP1ce/Slr7DUPU/4DFK/ardGo0sm6jm+jNx3fArFvT24u5P3rwjvsfs7ur5Kk FglJMrUd43c65aPMysHFfnErQDFFS1XsLf9GrpACfMv+IeWp9I8xEsCUFONvEqsCfr/q T2NqXlOUgXdzLwHYZdmS1wQ0LPk5RqlqpBG2A5QJwyiebhvCh4NTSwA5Ex2G1e0Wg1Vw Mu/g== 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=921nrX5AiF+PGtUex20DvxQS5yp5UWtiXxctFfZ7l3Q=; b=cz6Bzf2JRbCJvtM9qBz91X8vK+D2KE08/I7z/ujQrxolnSf84HYLbM+G9SpWZkPIU9 BapNeuUFWCyEbnlM5sd7E0qIgK5qFSubtRfnjRx1g1uWwxWdkXPNU1UsmsHyj9jYKbZt nnl6dGAWNv+I68Ma8QdnSRPYEAZgm/lATYaxIzIhyZfpDrQFenW4QYFL/8MutUhDsfaD 59Phalp3IwUmhyO9FKqSGI746+9QG+vVtUDwuJBF6OY+2Fn6YrDQFlmShKJzDLpB81GF A/tFZRePG5Z0LLG07E8iAx/8BRjTe9gvFD9AdKIDdWQJ3PQu6LPqfiP6R0Ai50XPm/3I y1/w== 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 b123si13335482pfa.14.2019.08.27.04.25.02; Tue, 27 Aug 2019 04:25:18 -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 S1727057AbfH0LYM (ORCPT + 99 others); Tue, 27 Aug 2019 07:24:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15173 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725912AbfH0LYM (ORCPT ); Tue, 27 Aug 2019 07:24:12 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4E160C057E9F; Tue, 27 Aug 2019 11:24:11 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id 81BCA3CCC; Tue, 27 Aug 2019 11:24:07 +0000 (UTC) Date: Tue, 27 Aug 2019 13:24:04 +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: <20190827132404.483a74ad.cohuck@redhat.com> In-Reply-To: References: <20190826204119.54386-1-parav@mellanox.com> <20190826204119.54386-2-parav@mellanox.com> <20190827122428.37442fe1.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.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 27 Aug 2019 11:24:11 +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: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 > > > > On Mon, 26 Aug 2019 15:41:16 -0500 > > Parav Pandit wrote: > > > > > Whenever a parent requests to generate mdev alias, generate a mdev > > > alias. > > > It is an optional attribute that parent can request to generate for > > > each of its child mdev. > > > mdev alias is generated using sha1 from the mdev name. > > > > Maybe add some motivation here as well? > > > > "Some vendor drivers want an identifier for an mdev device that is shorter than > > the uuid, due to length restrictions in the consumers of that identifier. > > > > Add a callback that allows a vendor driver to request an alias of a specified > > length to be generated (via sha1) for an mdev device. If generated, that alias is > > checked for collisions." > > > I did described the motivation in the cover letter with example and this design discussion thread. Yes, but adding it to the patch description makes it available in the git history. > I will include above summary in v1. > > > 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. > > > > * Parent device that support mediated device should be registered with > > mdev > > > * module with mdev_parent_ops structure. > > > **/ > > > @@ -92,6 +95,7 @@ struct mdev_parent_ops { > > > long (*ioctl)(struct mdev_device *mdev, unsigned int cmd, > > > unsigned long arg); > > > int (*mmap)(struct mdev_device *mdev, struct vm_area_struct > > *vma); > > > + unsigned int (*get_alias_length)(void); > > > }; > > > > > > /* interface for exporting mdev supported type attributes */ >