s/driver/documentation/ [LWN.net]

s/driver/documentation/

Posted Jul 5, 2010 17:50 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 we have full hardware documentation and we're expected to write our own userspace, then we also want to write our own kernel code.

Why? If the driver is good, accept it.

There's no incentive whatsoever for us to merge the upstream provided kernel code.

You get not to write that much code.

If we do then we provide an interface that we're expected to support forever (see the argument over nouveau breaking ABI), and the only consumer of that interface is a closed userspace driver.

Of course we should encourage an open source userspace driver, and with full documentation, there is really no reason not to open source the driver. But as a rule, adding a syscall should not require adding a consumer for that syscall.

(Log in to post comments)

s/driver/documentation/

Posted Jul 5, 2010 17:56 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

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.

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.