Re: [GIT PATCH] more Driver core patches for 2.6.19

[Michael K. Edwards]

On 12/13/06, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/