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]

Date:	Wed, 13 Dec 2006 12:58:24 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Greg KH <gregkh@...e.de>
cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19

On Wed, 13 Dec 2006, Greg KH wrote:
>
> It's a stupid test module for the uio core for isa devices.  It's not
> the main code, or core.

Doesn't matter.

IT IS SO FUNDAMENTALLY AND HORRIBLY WRONG THAT I REFUSE TO HAVE IT IN MY 
TREE.

As an "example", the _only_ thing it can possibly ever do is to just 
confuse people - in other words, it's an _anti_example, not a real one.

> Ok, I can pull this example module out if you want, but people seem to
> want examples these days.  If I do that, any objection to the rest?

I'm really not convinced about the user-mode thing unless somebody can 
show me a good reason for it. Not just some "wouldn't it be nice" kind of 
thing. A real, honest-to-goodness reason that we actually _want_ to see 
used.

No features just for features sake.

So please push the tree without this userspace IO driver at all. And if 
you actually have a real user, not just an example, that is worthy and 
shows why such a driver in user space is actually a good thing, _then_ we 
can push that.

In other words, I'd like to see code that uses this that is actually 
_better_ than an in-kernel driver in some way.

For USB, the user-mode thing made sense. You have tons of random devices, 
and the abstraction level is higher to begin with. Quite frankly, I simply 
don't even see the same being true for something like this.

Btw: there's one driver we _know_ we want to support in user space, and 
that's the X kind of direct-rendering thing. So if you can show that this 
driver infrastructure actually makes sense as a replacement for the DRI 
layer, then _that_ would be a hell of a convincing argument.

There may be others. Feel free to fill in the blank: ________.

		Linus
-
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/