| |||||||||||||
s/driver/documentation/s/driver/documentation/Posted Jul 5, 2010 18:02 UTC (Mon) by avik (guest, #704)In reply to: s/driver/documentation/ by mjg59 Parent article: A line in the sand for graphics drivers
If the interface isn't good enough for an open driver, you reject the patch. IOW existing code (open or closed) can not be used as an argument for forcing a bad API on the kernel.
You end up with one driver that can support both the (modified) closed user driver and a newly written open driver.
(Log in to post comments)
s/driver/documentation/ Posted Jul 5, 2010 20:23 UTC (Mon) by airlied (subscriber, #9104) [Link]
avik, I don't think you understand how complex these interfaces are.
Its not something you can assess in abstract form, i.e. until you've written a complete graphics driver, both kernel and userspace components you rarely know if the API you chose is going to be correct and performant. However you generally pick the 80% interface, go with that, and hope you can easily make the 100% interface on top of it later.
However unless a single group is developing the kernel and userspace drivers, generally that API is going to be useless and really constrain any one else. So we end up with a driver in the kernel providing an API that only a closed source userspace can exercise and an API that only a open source userspace can exercise, why should we introduce the first API at all.
I don't mind introducing reduced functionality kernel drivers that don't expose major userspace APIs to just serve as an example of how these GPUs work, I don't want a driver with an API commitment and no way for anyone to make sure the API continue working.
|
|||||||||||||