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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3AB16EB1049 for ; Tue, 10 Mar 2026 10:35:10 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8763110E113; Tue, 10 Mar 2026 10:35:09 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="m5uljI2K"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3749B10E113; Tue, 10 Mar 2026 10:35:08 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id B5105417C1; Tue, 10 Mar 2026 10:35:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C501C19423; Tue, 10 Mar 2026 10:35:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773138907; bh=o3jFtbDjVq5zxQWyC4adOecn3nFUZ4TF7ZRoY2jTlWY=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=m5uljI2Ka7GzfelDMbi9R1Wj/orOidAngK08ZDDKKF0nHYm5Ickl+hWJqTzZ/c5Ve t6Vl4F15Z1v4nPQaGFjZ8o/pNTOtJpq/OCYMwSBG/KPjSAlGhi0BFgOMrsiUh91VQ8 qfwGfyDOaFYquyHQtA7rdsOMyU59Uhhf0/Ce+rEGljMLNT/9jCGZPPSFF4s+kZ6liw s9KcXrz6aKXdZoSUF4kdvn+X/Z238a55uxUupNKgSlaxAHM6KsNeHO6f+8G3ZnIoqH 1IqxbWE1wOf/enu7gFSv81T65tiqLyIM2LGHJyFTHVLTkcV8ijY1uNt7A/McfNNVSu SWvgXjZNAsLAw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 10 Mar 2026 11:35:04 +0100 Message-Id: Subject: Re: [PATCH 3/9] gpu: nova-core: gsp: expose GSP-RM internal client and subdevice handles Cc: "Alexandre Courbot" , "Joel Fernandes" , "John Hubbard" , "Alice Ryhl" , "Simona Vetter" , , , , , "dri-devel" To: "Eliot Courtney" From: "Danilo Krummrich" References: <288fc58b-657c-4e8c-b6bc-d07afe14bb97@nvidia.com> In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue Mar 10, 2026 at 5:02 AM CET, Eliot Courtney wrote: > On Tue Mar 10, 2026 at 11:36 AM JST, Alexandre Courbot wrote: >> On Tue Mar 10, 2026 at 11:17 AM JST, Joel Fernandes wrote: >>>> On Mar 9, 2026, at 8:06=E2=80=AFPM, John Hubbard = wrote: >>>> On 3/9/26 4:41 PM, Joel Fernandes wrote: >>>>>>> On Mar 9, 2026, at 5:22=E2=80=AFPM, Joel Fernandes wrote: >>>>>> On Fri, Feb 27, 2026 at 09:32:08PM +0900, Eliot Courtney wrote: >>>>>>> + h_client: u32, >>>>>>> + h_subdevice: u32, >>>>>>=20 >>>>>> I would rather have more descriptive names please. 'client_handle', >>>>=20 >>>> Maybe it's better to mirror the Open RM names, which are ancient and >>>> well known in those circles. Changing them at this point is probably >>>> going to result in a slightly worse situation, because there are >>>> probably millions of lines of code out there that use the existing >>>> nomenclature. >>> >>> I have to disagree a bit here. Saying h_ in code is a bit meaningless: >>> there is no mention of the word "handle" anywhere near these fields. >>> h_ could mean "higher", "hardware", or any number of things. The only >>> reason I know it means "handle" is because of expertise with Nvidia >>> drivers. The `_handle` suffix is self-documenting; `h_` is not. >> >> I tend to agree with Joel that we should try to avoid NVisms when they >> get in the way of clarity - that's what we did so far actually. We can >> always mention the RM name of fields in the doccomments. >> >> The only exception being generated bindings, but they reside in their >> own module and are opaque to the rest of the driver. > > Thanks everyone for your comments so far. I don't mind about the naming, > I can see both arguments. But we have two votes for different names for > h_client/h_subdevice/etc so far, so I'll go with that for now. If anyone > has any other suggested names keen to hear. Please don't mirror names from other drivers (regardless whether it is Open= RM, nouveau, etc.) just to be consistent with the naming of other drivers. If t= he name is good, great, otherwise please pick what makes the most sense. In this case h_client and h_subdevice aren't great names at all. I don't wa= nt to establish a pattern where we prefix handles with 'h' to distinguish them fr= om other values. There is no reason to have such a convention if we can just represent a handle through a proper type (which has other advantages as well), i.e. we = don't need to resolve any ambiguity due to a primitive type. For instance, we could have a gsp::Handle type and then this could just bec= ome: client: gsp::Handle, subdev: gsp::Handle, If we want type safety to a point where we can't even confuse different typ= es of handles, we could give them a type state, so we don't have to re-implement = the same thing multiple times, e.g. client: gsp::Handle, subdev: gsp::Handle, I.e. when a method expects a client handle, nothing else can be passed it. - Danilo