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 PM, John Hubbard <[email protected]> wrote:
>>>> On 3/9/26 4:41 PM, Joel Fernandes wrote:
>>>>>>> On Mar 9, 2026, at 5:22 PM, Joel Fernandes <[email protected]>
>>>>>>> wrote:
>>>>>> On Fri, Feb 27, 2026 at 09:32:08PM +0900, Eliot Courtney wrote:
>>>>>>> + h_client: u32,
>>>>>>> + h_subdevice: u32,
>>>>>>
>>>>>> I would rather have more descriptive names please. 'client_handle',
>>>>
>>>> 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 the
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 want to
establish a pattern where we prefix handles with 'h' to distinguish them from
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 become:
client: gsp::Handle,
subdev: gsp::Handle,
If we want type safety to a point where we can't even confuse different types 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<Client>,
subdev: gsp::Handle<Subdev>,
I.e. when a method expects a client handle, nothing else can be passed it.
- Danilo
