lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5bd4ffa9-f44f-ca34-c346-6c530d31e5ec@suse.de>
Date:   Fri, 12 Nov 2021 11:57:21 +0100
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Pekka Paalanen <ppaalanen@...il.com>
Cc:     Jani Nikula <jani.nikula@...el.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Michel Dänzer <michel@...nzer.net>,
        Javier Martinez Canillas <javierm@...hat.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Peter Robinson <pbrobinson@...il.com>
Subject: Re: [PATCH v4 0/6] Cleanups for the nomodeset kernel command line
 parameter logic

Hi

Am 12.11.21 um 11:22 schrieb Pekka Paalanen:
> On Fri, 12 Nov 2021 11:09:13 +0100
> Thomas Zimmermann <tzimmermann@...e.de> wrote:
> 
>> Hi
>>
>> Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas:
>>> Hello Pekka,
>>>
>>> On 11/12/21 09:56, Pekka Paalanen wrote:
>>>
>>> [snip]
>>>    
>>>>
>>>> Hi,
>>>>
>>>> these ideas make sense to me, so FWIW,
>>>>
>>>> Acked-by: Pekka Paalanen <pekka.paalanen@...labora.com>
>>>>   
>>>
>>> Thanks.
>>>    
>>>> There is one nitpick I'd like to ask about:
>>>>
>>>> +bool drm_get_modeset(void)
>>>> +{
>>>> +     return !drm_nomodeset;
>>>> +}
>>>> +EXPORT_SYMBOL(drm_get_modeset);
>>>>
>>>> Doesn't "get" have a special meaning in the kernel land, like "take a
>>>> strong reference on an object and return it"?
>>>
>>> That's a very good point.
>>>    
>>>> As this is just returning bool without changing anything, the usual
>>>> word to use is "is". Since this function is also used at most once per
>>>> driver, which is rarely, it could have a long and descriptive name.
>>>>
>>>> For example:
>>>>
>>>> bool drm_is_modeset_driver_allowed(void);
>>
>> I'd nominate
>>
>>     bool drm_native_drivers_enabled()
>>
>> This is what HW-specific drivers want to query in their init/probing
>> code. The actual semantics of this decision is hidden from the driver.
>> It's also easier to read than the other name IMHO
> 
> Ok, but what is a "native driver"? Or a "non-native driver"?
> Is that established kernel terminology?
> 
> I'd think a non-native driver is something that e.g. ndiswrapper is
> loading. Is simpledrm like ndiswrapper in a sense? IIRC, simpledrm is
> the driver that would not consult this function, right?

We use that term for hw-specific drivers. A 'non-native' driver would be 
called generic or firmware driver.

My concern with the 'modeset' term is that it exposes an implementation 
detail, which can mislead a driver to to the wrong thing: a HW-specifc 
driver that disables it's modesetting functionality would pass the test 
for (!modeset). But that's not what we want, we want to disable all of 
the driver and not even load it.

How about we invert the test function and use something like

  bool drm_firmware_drivers_only()

? HW-native drivers can do

   if (drm_firmware_drivers_only())
     return;

as early as possible. fbdev uses the flag FBINFO_MISC_FIRMWARE to mark 
rsp drivers. So the terminology is there already.

Best regards
Thomas

> 
> 
> Thanks,
> pq
> 
>>
>> Best regards
>> Thomas
>>
>>>>   
>>>
>>> Yeah, naming is hard. Jani also mentioned that he didn't like this
>>> function name, so I don't mind to re-spin the series only for that.
>>>    
>>>> - "drm" is the namespace
>>>> - "is" implies it is a read-only boolean inspection
>>>> - "modeset" is the feature being checked
>>>> - "driver" implies it is supposed gate driver loading or
>>>>     initialization, rather than modesets after drivers have loaded
>>>> - "allowed" says it is asking about general policy rather than what a
>>>>     driver does
>>>>   
>>>
>>> I believe that name is more verbose than needed. But don't have a
>>> strong opinion and could use it if others agree.
>>>    
>>>> Just a bikeshed, I'll leave it to actual kernel devs to say if this
>>>> would be more appropriate or worth it.
>>>>   
>>>
>>> I think is worth it and better to do it now before the patches land, but
>>> we could wait for others to chime in.
>>>
>>> Best regards,
>>> --
>>> Javier Martinez Canillas
>>> Linux Engineering
>>> Red Hat
>>>    
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ