linux-kernel - Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via

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: <21d7e9970907201531s45a55493od827034a0f26f4c8@mail.gmail.com>
Date:	Tue, 21 Jul 2009 08:31:55 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Stephane Marchesin <marchesin@...s.u-strasbg.fr>
Cc:	Thomas Hellström <thomas@...pmail.org>,
	Christoph Hellwig <hch@...radead.org>,
	DRI <dri-devel@...ts.sourceforge.net>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: DRM drivers with closed source user-space: WAS [Patch 0/3] 
	Resubmit VIA Chrome9 DRM via_chrome9 for upstream

2009/7/21 Stephane Marchesin <marchesin@...s.u-strasbg.fr>:
> 2009/7/20 Thomas Hellström <thomas@...pmail.org>:
>>
>> 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..
>>
>
> Well, for user space, there can be as many drivers as you want for a
> given device. But the DRM policy always was one driver per hardware so
> as to avoid confusing people, so what you're proposing is in fact not
> possible. In that case, this would even deter a fully open source
> driver as it would have to keep the same interface as some (possibly
> unsupported) driver.

Well with KMS it sort of changes that a small bit, since a KMS driver really
isn't required to share old interfaces, since having a KMS enabled
kernel will break any
userspace that is out there just by setting up the hw different. as
long as the old
code is still available in the backwards compat manner it should all be fine.

We've also had two drm drivers before, i830 and i915 supported a lot
of the same hw
and it mostly worked, if you looked at it from a kernel perspective.

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