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] [day] [month] [year] [list]
Date:   Fri, 13 Apr 2018 16:53:12 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Thomas Huth <thuth@...hat.com>
Cc:     Gustavo Padovan <gustavo@...ovan.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Sean Paul <seanpaul@...omium.org>,
        David Airlie <airlied@...ux.ie>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        borntraeger@...ibm.com, Farhan Ali <alifm@...ux.ibm.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Gerd Hoffmann <kraxel@...hat.com>
Subject: Re: [PATCH 0/2] drm: Make it compilable without CONFIG_HDMI and CONFIG_I2C

On Fri, Apr 13, 2018 at 4:46 PM, Thomas Huth <thuth@...hat.com> wrote:
> On 13.04.2018 16:32, Daniel Vetter wrote:
>> On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth <thuth@...hat.com> wrote:
>>> By enabling the DRM code for virtio-gpu on S390, you currently also get
>>> all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automatically.
>>> This is quite ugly, since on S390, there is no HDMI and no I2C. Thus it
>>> would be great if the DRM code could also be compiled without CONFIG_HDMI
>>> and CONFIG_I2C. These two patches now refactor the DRM code a little bit
>>> so that we can compile it also without CONFIG_HDMI and CONFIG_I2C.
>>>
>>> Thomas Huth (2):
>>>   drivers/gpu/drm: Move CONFIG_HDMI-dependent code to a separate file
>>>   drivers/gpu/drm: Make the DRM code compilable without CONFIG_I2C
>>
>> What's the benefit? Why does I2C/HDMI hurt you?
>
> Why should I be forced to compile-in subsystems that do not make any
> sense on this architecture? It's just completely weird to see CONFIG_I2C
> enabled on s390x.

"Looks wierd" is not really a good engineering criteria, especially in
graphics :-)

For context: In DRM almost nothing is optional, and it greatly
simplifies life and coding. We don't have epic amounts of #ifdef
battles to make trivial code changes compile, except in all the places
where external stuff is optional (like backlight).

So making something optional will have a pretty clear cost on the drm
subsystem, and it doesn't make sense to pay that cost to "look less
wierd". To get this merged we need some clear benefits, which will
balance out the inevitable cost of having to maintain this forever
(and most likely getting yelled at by Linus for making some rando
compile config no longer work).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ