User: Password:
|
|
Subscribe / Log in / New account

s/driver/documentation/

s/driver/documentation/

Posted Jul 5, 2010 17:56 UTC (Mon) by mjg59 (subscriber, #23239)
In reply to: s/driver/documentation/ by avik
Parent article: A line in the sand for graphics drivers

Because merging the upstream kernel component requires either slavishly adopting the same interface (and thus limiting our ability to write a driver), keeping one kernel driver that supports two different interfaces (maintenance nightmare) or providing two different kernel drivers (one of which will probably end up bitrotting). If the only consumer of the kernel code is a closed driver, we don't want it. If accepting it constrains our ability to write an open driver, we don't want it. In summary - we don't want it. It's great as an example of driving the hardware, and if it comes with documentation it's an excellent basis for the driver that does actually get merged. But it's not going into the kernel.


(Log in to post comments)

s/driver/documentation/

Posted Jul 5, 2010 18:02 UTC (Mon) by avik (guest, #704) [Link]

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.

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds