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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f2b55d220612131539jdbaf6e2g3444d7f77b9a1421@mail.gmail.com>
Date:	Wed, 13 Dec 2006 15:39:28 -0800
From:	"Michael K. Edwards" <medwards.linux@...il.com>
To:	tglx@...utronix.de
Cc:	"Benjamin Herrenschmidt" <benh@...nel.crashing.org>,
	"Linus Torvalds" <torvalds@...l.org>, "Greg KH" <gregkh@...e.de>,
	"Andrew Morton" <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19

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