On 12/13/06, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
Aside of that there are huge performance gains for certain application / driver scenarios and I really don't see an advantage that people are doing excactly the same thing in out of tree hackeries with a lot of inconsistent user land interfaces.
Greg's effort is noble but I think it is targeted at the wrong problem and would actually make things worse. Inconsistent interfaces from one "driver" to another are the surface design flaw that obscures the fundamental design flaw of exposing hardware to userland: abdication of the driver writer's responsibility to choose and justify which things belong in the driver and which belong in a hardware-agnostic driver framework or a userspace library instead. When you are talking about unique, one-off hardware, it doesn't really matter whether the shim for a closed, out-of-tree, userspace driver fits into a framework or not. Who cares whether they use the preferred MMIO reservation paths or just throw ioctl(POKE_ME_HARDER) or mmap(/dev/mem) at the problem? But I don't want to see ALSA or iwconfig or i2c-core or any of the other competently designed and implemented driver frameworks mangled into unusability by attempts to facilitate this "design pattern". Truth in advertising is an advantage even if it doesn't change the underlying reality. I can (and do) tell chip vendors, "that's not a driver, that's a shim for some other customer's pre-existing eCos task", and justify the cost of writing an actual driver to the client. I may or may not succeed in arguing that the new driver should be designed to an existing API when that means rethinking the userspace app, or that it should be implemented against a current kernel and offered promptly up to the appropriate Linus lieutenant. But at least the project isn't crippled by confusion about whether or not the existing blob constitutes a driver. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
