On Fri, Jul 2, 2010 at 10:08 AM, Daniel Walker <dwalker@xxxxxxxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
