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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
