Prev: [patch 006/164] oprofile: remove double ring buffering
Next: serial: fix rs485 for atmel_serial on avr32
From: Dave Airlie on 1 Jul 2010 18:40
On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie <airlied(a)gmail.com> wrote:
> Now this is just my opinion as maintainer of the drm, and doesn't
> reflect anyone or any official policy, I've also no idea if Linus
> agrees or not.
>
> We are going to start to see a number of companies in the embedded
> space submitting 3D drivers for mobile devices to the kernel. I'd like
> to clarify my position once so they don't all come asking the same
> questions.
>
> If you aren't going to create an open userspace driver (either MIT or
> LGPL) then don't waste time submitting a kernel driver to me.
>
> My reasons are as follows, the thing is you can probably excuse some
> of these on a point by point basis, but you need to justify why closed
> userspace on all points.
>
> a) licensing, Alan Cox pointed this out before, if you wrote a GPL
> kernel driver, then wrote a closed userspace on top, you open up a
> while world of derived work issues. Can the userspace operate on a
> non-GPL kernel without major modifications etc. This is a can of worms
> I'd rather not enter into, and there are a few workarounds.
>
> b) verifying the sanity of the userspace API.
> 1. Security: GPUs can do a lot of damage if left at home alone, since
> mostly you are submitting command streams unverified into the GPU and
> won't tell us what they mean, there is little way we can work out if
> the GPU is going to over-write my passwd file to get 5 fps more in
> quake. Now newer GPUs have at least started having MMUs, but again
> we've no idea if that is the only way they work without docs or a lot
> of trust.
>
> 2. General API suitability and versioning. How do we check that API is
> sane wrt to userspace, if we can't verify the userspace. What happens
> if the API has lots of 32/64 compat issues or things like that, and
> when we fix them the binary userspace breaks? How do we know, how do
> we test etc. What happens if a security issue forces us to break the
> userspace API? how do we fix the userspace driver and test to confirm?
>
> c) supplying docs in lieu of an open userspace
> If you were to fully document the GPU so we could verify the
> security/api aspects it leaves us in the position of writing our own
> driver. Now writing that driver on top of the current kernel driver
> would probably limit any innovation, and most people would want to
> write a new kernel driver from scratch. Now we end up with two drivers
> fighting, how do we pick which one to load at boot? can we ever do a
> generic distro kernel for that device (assuming ARM ever solves that
> issue).
>
> I've also noticed a trend to just reinvent the whole wheel instead of
> writing a drm/kms driver and having that as the API, again maintainer
> nightmares are made of this.
>
> Dave.

Oh and (one other thought)

d) you are placing the maintenance burden in the wrong place

So you've upstreamed the kernel bits, kept the good userspace bits to
yourselfs, are stroking them on your lap like some sort of Dr Evil,
now why should the upstream kernel maintainers take the burden when
you won't actually give them the stuff to really make their hardware
work? This goes for nvidia type situations as well, the whole point is
to place the maintainer burden at the feet of the people causing the
problems in an effort to make them change. Allowing even an hour of
that burden to be transferred upstream, means more profit for them,
but nothing in return for us.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 1 Jul 2010 19:00
On Fri, Jul 2, 2010 at 8:51 AM, Daniel Walker <dwalker(a)codeaurora.org> wrote:
> On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
>> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie <airlied(a)gmail.com> wrote:
>> > Now this is just my opinion as maintainer of the drm, and doesn't
>> > reflect anyone or any official policy, I've also no idea if Linus
>> > agrees or not.
>> >
>> > We are going to start to see a number of companies in the embedded
>> > space submitting 3D drivers for mobile devices to the kernel. I'd like
>> > to clarify my position once so they don't all come asking the same
>> > questions.
>> >
>> > If you aren't going to create an open userspace driver (either MIT or
>> > LGPL) then don't waste time submitting a kernel driver to me.
>
> If , for whatever reason, you changed you mind on this what sort of
> connection between kernel and userspace would these components use?
>
> I ask only because I think UIO hold most (if not all) the driver in
> userspace .. So you would have to use some other interface if you wanted
> a more half and half solution ..
>

The thing is UIO doesn't solve the problem 3D graphics drivers need to
solve. Which is we need to let unprivileged users access the graphics
device in an efficient manner, hence why DRI/DRM exists. Now I think
the tegra guys have done some evil hacks with a userspace daemon to
replace the kernel functionality, so all they have in-kernel is a
framebuffer device, since they can't really get away with shipping the
binary nvidia driver linked to the kernel in a real device. So all
their userspace closed bits talk to the daemon running as root with
direct access to the lowlevel hw.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Saravana Kannan on 1 Jul 2010 20:20
Dave Airlie wrote:
> This is more about initial development stages. We maintain kernel
> API/ABI for all in-tree drivers, however before we put a driver into
> mainline, we usually need to redo the crazy interfaces that vendors
> have come up with. Like 32/64 alignment, passing userspace addresses
> into the kernel, passing phy addresses to userspace etc. If the
> userspace binary is closed that process becomes next to impossible.

My 2 cents:
I think we should leave the onus of fixing the userspace to work with
the sane kernel API with the entity trying to get their drivers into the
kernel. I think it's a better approach (as in, more likelihood of
getting device support) than saying, we will only allow fully open
sourced kernel drivers.

-Saravana
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Timothy Meade on 1 Jul 2010 20:50
---------- Forwarded message ----------
From: Timothy Meade <zt.tmzt(a)gmail.com>
Date: Thu, Jul 1, 2010 at 8:38 PM
Subject: Closed source userspace graphics drivers with an open source
kernel component
To: Saravana Kannan <skannan(a)codeaurora.org>
Cc: LKML <linux-kernel(a)vger.kernel.org>, dri-devel
<dri-devel(a)lists.freedesktop.org>, linux-arm-msm(a)vger.kernel.org,
jcrouse(a)codeaurora.org



On Thu, Jul 1, 2010 at 8:18 PM, Saravana Kannan <skannan(a)codeaurora.org> wrote:
>
> Dave Airlie wrote:
>>
>> This is more about initial development stages. We maintain kernel
>> API/ABI for all in-tree drivers, however before we put a driver into
>> mainline, we usually need to redo the crazy interfaces that vendors
>> have come up with. Like 32/64 alignment, passing userspace addresses
>> into the kernel, passing phy addresses to userspace etc. If the
>> userspace binary is closed that process becomes next to impossible.
>
> My 2 cents:
> I think we should leave the onus of fixing the userspace to work with the sane kernel API with the entity trying to get their drivers into the kernel. I think it's a better approach (as in, more likelihood of getting device support) than saying, we will only allow fully open sourced kernel drivers.
>
> -Saravana
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at �http://vger.kernel.org/majordomo-info.html


Hello.� I've been working with the developers on the htc-linux project
and following the progress of Android on MSM devices closely for a few
years.� I've been excitied to see DRM/DRI replace PMEM and the Android
specific interfaces be replaced with more Linux-like ones.� The Xorg
driver from Qualcomm uses this same interface for 2D and it's possible
that Android will take the same approach, though it uses 3D and GLES
as a type of abstraction layer for surfaceflinger.� This allows for a
closed 3D driver with an open command submission layer that is in
itself not that different from the split for ATI devices using
radeonhd.� I say this because the alternative for these devices is a
fully closed binary and secrecy surrounding the graphics layers that
ensures that only the OS that ships with the device can ever really be
used and preventing those non-coorporate developers as myself from
utilising GPL code the way we want or even usuing are own cell phones
(in this case).� I would choose a fully open, X based OS even if that
meant only having 2D drivers, but I know that Quic and others aren't
going to develop just a (accelerated) 2D driver, not the kernel
components or userspace but instead rely on the same GLES layer that
Android uses, essentially making X and open environments a second
class citizen on modern mobile hardware.

I hope those making the decision will take this into consideration.

--
Timothy Meade (tmzt on freenode)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Corbin Simpson on 1 Jul 2010 21:30
I thought Intel shelved Larrabee.

~ C.

On Thu, Jul 1, 2010 at 4:51 PM, Piotr Gluszenia Slawinski
<curious(a)bwv190.internetdsl.tpnet.pl> wrote:
>> We are going to start to see a number of companies in the embedded
>> space submitting 3D drivers for mobile devices to the kernel. I'd like
>> to clarify my position once so they don't all come asking the same
>> questions.
>
> one of options for future would be equipping gpu's with additional
> processing force, allowing it to run whole Xorg on it's own,
> and just communicate with rest of machine via shared memory window (so
> visible as 'hardware X server' from systems standpoint),
>
> option which allows both - closing 'source' of gpu , and taking
> off burden of development for closed, once-use-throwaway
> devices from Xorg and kenel crew.
>
> also port of Xorg on GPUs itself allows skipping a lot of features
> of kernel, and OS itself (it doesn't to be based on linux afterall)
> allowing much more robust performance, and skipping common bottlenecks
> (sharing irq's , scheduling, etc)
>
> but this route needs to be considered by hardware vendors themselves.
>
> --
>
> _______________________________________________
> dri-devel mailing list
> dri-devel(a)lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>



--
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude(a)gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: [patch 006/164] oprofile: remove double ring buffering
Next: serial: fix rs485 for atmel_serial on avr32