Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream

[Dave Airlie]

2009/7/21 Thomas Hellström <thomas@xxxxxxxxxxxx>:
> Stephane Marchesin wrote:
>>>
>>> You obviously got all this completely wrong.
>>>
>>> I avoid writing closed source drivers whenever I can, I'm not whining and
>>> I'm not trying to push any of them. The code VIA is trying to submit has
>>> not
>>> been written by me nor anybody I know. All VIA code I and the companies
>>> I've
>>> worked for has written is open-sourced and contributed to the Openchrome
>>> /
>>> mesa / drm project.
>>>
>>> The point I'm trying to make is the following:
>>>
>>> If the common agreement of the linux community is to *NOT* allow these
>>> drivers in, so be it, then be honest and go ahead and tell the driver
>>> writers. Don't make them respin their development trying to fix minor
>>> flaws
>>> when their driver won't get in anyway!
>>>
>>>
>>
>>
>
> Stephane,
> Some comments on how these things has been handled / could be handled.
>>
>> I would like to raise a couple of real-life issues I have in mind:
>>
>> * First example, let's say VIA gets their Chrome9 DRM merged into the
>> kernel. Now let's say I reverse engineer the hardware (or use the docs
>> whenever they're available) and write a 3D component that needs
>> modifications to the existing DRM interface (or maybe I realize I need
>> a completely new DRM). Then who gets the upper hand? Do I have to keep
>> compatibility with user space binary modules that I do not care about?
>>
>
> If there is a serious OS project, I'd start a new DRM driver.
> That's sort of what may happen with openChrome vs via..
>
>> * Second example, what is the policy if we find security holes in the
>> DRM for a closed user-space afterwards? This breaks the initial
>> promise of security, does that get the driver removed then? Or what if
>> the promise is pending updated documentation that never arrives?
>>
>
> I'd say the DRM driver gets disabled unless fixed. How would we handle that
> problem today with, for example, the SiS driver?
>
>> * Third example, what if down the line we need changes in the DRM that
>> require updating all DRM modules. Do we (we as in DRM developers)
>> touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking
>> the code (since we don't test with proprietary modules)? Or do we let
>> the Chrome9 files as-is, keeping the old DRM infrastructure and
>> therefore add more and more DRM cruft?
>>
>
> Again, this has been done quite commonly in the past and was easier to get
> right with the old drm.git testing ground. Same issue with unmaintained
> drivers with OS user-space. Who has actually tested all the drivers when
> making such a change? I certainly haven't. The change was left for testing
> for a while in drm.git before Dave moved it upstream.
>
>> In my opinion, accepting GPL'ed DRM modules that support binary user
>> space components is like opening pandora's box.
>>
>> Stephane
>>
>
> Yeah, drivers supporting binary blobs only is out of the question as it
> seems.
>
> Now's the tricky question how do we handle VIA's patches where they claim
> they have an open-source 2D component that exercises all of the DRM module
> for EXA render acceleration, and on top of this the 3D binary driver that
> apparently uses no additional DRM functionality compared to the 2D
> component?
>
> In the ideal world I'd of course like to see a Chrome9 3D driver based of
> the new openChrome drm driver with a modern GPU memory manager, kernel
> modesetting and Gallium, but that's a dedicated man-year or more away if /
> when someone decides to work on it.
>

If VIA releases the DDX code to use the DRM code, and it exercises the ioctls
then we can add kernel support for the ioctls the DDX uses. If there a bunch
of ioctls specific to the 3D driver we should identify them and see if userspace
test code is available.

I think this is the same as when poulsbo was proposed, if open code uses
the interfaces we add them, if not we don't.

I'd also prefer a community approach to work more on the new world order
and ignore this interface.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/