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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 7FA29C83004 for ; Tue, 28 Apr 2020 11:19:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5B9DB206D7 for ; Tue, 28 Apr 2020 11:19:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588072752; bh=IqAMOHRQi5uhfCVr5Lrx2IsDNQawBGQ/zPDlgP6XhKQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=MSI8BxZHdE9jWPq/SPTKGpCBSGSkMHiUyYJPI4selyQ47a5gk7DJp/7/AlKOrhnFu 9yKYFWXs6xwSMmCd8+hz/GC8Urwgk1hiOi8cc2vFOsDvKhpDFA6eqKkoUly86+l0mX +XrWmvsDKS1O6LC22lpHr/ne74m4c7mow5m8mBTc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726566AbgD1LTL (ORCPT ); Tue, 28 Apr 2020 07:19:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:37414 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726450AbgD1LTL (ORCPT ); Tue, 28 Apr 2020 07:19:11 -0400 Received: from localhost (unknown [213.57.247.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6780A206D6; Tue, 28 Apr 2020 11:19:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588072751; bh=IqAMOHRQi5uhfCVr5Lrx2IsDNQawBGQ/zPDlgP6XhKQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vheSVMLeHPktCnH0uuVXXmloZpjo9DhbF26ZBwKvmo6GlxrDwlgBEb2OydFUFafHG maiBV/+mWZavVHEDLeBgZpT6iG6c/qtVy8qZyRH1yHBsYv/GlvXZZ3qE2z4eqh1YQi XYe4zXrGvSp2M+iTBC6VAjwC4A6ZQ1qGQkkJPUr8= Date: Tue, 28 Apr 2020 14:19:07 +0300 From: Leon Romanovsky To: liweihang Cc: Jason Gunthorpe , "dledford@redhat.com" , "linux-rdma@vger.kernel.org" , Linuxarm , "selvin.xavier@broadcom.com" , "devesh.sharma@broadcom.com" , "somnath.kotur@broadcom.com" , "sriharsha.basavapatna@broadcom.com" , "bharat@chelsio.com" , "galpress@amazon.com" , "sleybo@amazon.com" , "faisal.latif@intel.com" , "shiraz.saleem@intel.com" , "yishaih@mellanox.com" , "mkalderon@marvell.com" , "aelior@marvell.com" , "benve@cisco.com" , "neescoba@cisco.com" , "pkaustub@cisco.com" , "aditr@vmware.com" , "pv-drivers@vmware.com" , "monis@mellanox.com" , "kamalheib1@gmail.com" , "parav@mellanox.com" , "markz@mellanox.com" , "rd.dunlab@gmail.com" , "dennis.dalessandro@intel.com" Subject: Re: [PATCH for-next] RDMA/core: Assign the name of device when allocating ib_device Message-ID: <20200428111907.GI134660@unreal> References: <1587893517-11824-1-git-send-email-liweihang@huawei.com> <20200427114734.GC134660@unreal> <20200427115201.GN26002@ziepe.ca> <20200427120337.GD134660@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Tue, Apr 28, 2020 at 08:00:29AM +0000, liweihang wrote: > On 2020/4/27 20:03, Leon Romanovsky wrote: > >>>> /** > >>>> * _ib_alloc_device - allocate an IB device struct > >>>> * @size:size of structure to allocate > >>>> + * @name: unique string device name. This may include a '%' which will > >>> It looks like all drivers are setting "%" in their name and "name" can > >>> be changed to be "prefix". > >> Does hfi? I thought the name was forced there for some port swapped > >> reason? > > This patch doesn't touch HFI, nothing prohibits from us to make this > > conversion work for all drivers except HFI and for the HFI add some > > different callback. There is no need to make API harder just because > > one driver needs it. > > > > Thanks > > > >> Jason > > Hi Jason and Leon, > > I missed some codes related to assign_name() in this series including > hfi/qib as Shiraz pointed. And I found a "name" without a "%" in following > funtions in core/nldev.c, and ibdev_name will be used for rxe/siw later. > > static int nldev_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, > struct netlink_ext_ack *extack) > { > ... > > nla_strlcpy(ibdev_name, tb[RDMA_NLDEV_ATTR_DEV_NAME], > sizeof(ibdev_name)); > if (strchr(ibdev_name, '%') || strlen(ibdev_name) == 0) > return -EINVAL; > > ... > } > > I'm not familiar with these codes, but I think the judgment in assign_name() > is for the situaion like above. > > if (strchr(name, '%')) > ret = alloc_name(device, name); > else > ret = dev_set_name(&device->dev, name); > > So is it a better idea to keep using "name" instead of "prefix"? nldev_newlink() doesn't call to ib_alloc_device() and alloc_name(). The check pointed by you is for the user input. > > Thanks > Weihang