Message-ID: <1278029284.7738.116.camel@c-dwalke-linux.qualcomm.com>
Date:	Thu, 01 Jul 2010 17:08:04 -0700
From:	Daniel Walker <dwalker@...eaurora.org>
To:	Dave Airlie <airlied@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	linux-arm-msm@...r.kernel.org, jcrouse@...eaurora.org
Subject: Re: Closed source userspace graphics drivers with an open source 
 kernel component

On Fri, 2010-07-02 at 09:37 +1000, Dave Airlie wrote:

> > Oh, man .. It seems like any driver model that straddles userspace and
> > kernel space is kind of asking for trouble (my opinion anyway)..
> >
> > Would you accept a userspace component that supported some subset of the
> > features ? You would have a kernel space driver, and userspace both open
> > source and GPL'd , but the userspace component wouldn't support ever
> > feature available .. Then the company would be free to make another
> > proprietary userspace with more features based off the open source one.
> >
> 
> That starts to get a bit more towards useful, except you still run
> into the problem of what happens if community developers start adding
> features to the open driver, that conflict with  features in the
> closed code. We'd also have to be very careful about what interfaces
> the kernel exposed had corresponding code in userspace. i.e. adding
> "special" ioctls for the closed bits would be a disaster, all such
> ioctls would need open users for verification and testing.

Ok .. The open userspace would just be like any other project, but
whatever company pushed the driver would likely maintain the userspace
component .. So the maintainer would have to handle the conflicts
between the proprietary vs. open source sides of it.

Actually , now that I think about it the biggest problem is the license
of the userspace side.. Whatever company makes this would have to be
able to relicense it and actually make a proprietary userspace.. So the
userspace license would be really critical.. Either that or no one
outside the company that pushed the driver could make code changes to
the userspace side..

> So for example, if you have a kernel KMS/DRM driver, and it set the
> hardware up, but then you had an open 2D driver and a closed 3D
> driver, you would have to make sure there was no functionality in the
> kernel that only the 3D driver used as it would become impossible to
> openly validate it.

Ok. I'm not sure how crazy that would be to setup, but it doesn't seem
like it would be that hard to just abstract the various components of
the driver.

> The other issue I see with a lot of these, is the driver are presented
> as this is the kernel driver, these APIs are set in stone as we have
> binary userspaces already deployed, this is even more unacceptable,
> since we need to be able to change the interface and do proper driver
> design before merging what looks like crap thrown together in a pile
> and made to stick.

This seems really wild to me .. Your talking about how you change the
kernel space side and you need to be able to change the userspace side
to match right ?

Where does the userspace side of these driver live? Not in the kernel
right?

Daniel

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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/

Powered by blists - more mailing lists