Re: [PATCH 0/2] drm: Make it compilable without CONFIG_HDMI and CONFIG_I2C
- Date: Fri, 13 Apr 2018 16:53:12 +0200
- From: Daniel Vetter <daniel@xxxxxxxx>
- 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@xxxxxxxxxx> wrote:
> On 13.04.2018 16:32, Daniel Vetter wrote:
>> On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth <thuth@xxxxxxxxxx> 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
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).
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch