On Fri, Jul 2, 2010 at 10:08 AM, Daniel Walker dwalker@codeaurora.org wrote:
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..
We generally use MIT for userspace bits anyways, I don't think we have any LGPL/GPL drivers in userspace currently. So this would probably be an okay solution to continue with.
The thing is with architectures like Gallium it would be possible to write a complete open driver and just keep the Windows interface bits, granted we don't have an open gallium to windows driver layer so that would have to be worked on.
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.
Its pretty much what something like gallium can do.
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?
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.
Dave.