| |||||||||||||
s/driver/documentation/s/driver/documentation/Posted Jul 5, 2010 17:35 UTC (Mon) by avik (guest, #704)In reply to: s/driver/documentation/ by mjg59 Parent article: A line in the sand for graphics drivers
Once you're at the point of something as complex as a graphics driver, interface documentation is unlikely to be both precise and accurate.Then the driver+documentation is unlikely to be accepted. We need to insist on quality docs, just as we insist on quality code. Say we end up with an open kernel driver, a closed userspace implementation and an open userspace implementation. Part of the interface documentation can be interpreted in two different ways, and interpreting it one way gives a significant performance boost to the open component and breaks the closed component. Do we accept the patch or refuse the patch?We request a clarification to the specification.
What if one interpretation allows DMAing to arbitrary addresses?Then it's clearly a bug. Both driver and documentation need to be fixed. None of the above change when you get an open source driver instead of documentation. In fact, a driver is less likely to be complete (since it won't implement all capabilities), though more likely to be accurate (since it can be tested). Documentation contains a superset of the information in a driver, since you can write a driver based on the documentation, but you can't write the entire documentation from reading the driver source. And this ignores the fact that any interface documentation for a graphics driver's kernel component is likely to be of the form "This ioctl submits a buffer of GPU commands to the device".Such documentation should be rejected. Documentation should describe exactly what happens with the bits, either directly or by referring to hardware documentation.
These commands will typically not be interpreted by the kernel code beyond certain sanity checking, so documenting the interface does little to tell us how to implement a userspace version of the same code. Interface documentation is better than no interface documentation, and hardware documentation is better still.what you describe is not an interface documentation, but a tunnel documentation. That should be rejected. But if we have a kernel component with a well-defined ABI then that impairs our ability to implement a userspace driver unless we also develop a parallel kernel component. And that way lies madness.Certainly, I got confused just reading that last paragraph.
(Log in to post comments)
s/driver/documentation/ Posted Jul 5, 2010 17:40 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
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. There's no incentive whatsoever for us to merge the upstream provided kernel 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.
s/driver/documentation/ Posted Jul 5, 2010 17:50 UTC (Mon) by avik (guest, #704) [Link] 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.
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.
|
|||||||||||||