linux-kernel - Re: [RFC] Pushing device/driver binding decisions to userspace

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: <1163381067.5178.301.camel@gullible>
Date:	Sun, 12 Nov 2006 17:24:27 -0800
From:	Ben Collins <ben.collins@...ntu.com>
To:	Nicholas Miell <nmiell@...cast.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Pushing device/driver binding decisions to userspace

On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> 
> What's wrong with making udev or whatever unbind driver A and then bind
> driver B if the driver bound by the kernel ends up being the wrong
> choice? (Besides the inelegance of the kernel choosing one and then
> userspace immediately choosing the other, of course.)
> 
> I'd argue that having multiple drivers for the same hardware is a bit
> strange to begin with, but that's another issue entirely.

If two drivers are loaded for the same device, there's no way for udev
to tell the kernel which driver to use for a device, that I know of.

Also, that just sounds very horrible to do. If you have udev/dbus events
flying around for "device present", "device gone", "device present",
then it could make for a very ugly user experience (think of programs to
handle devices being started because of these events).
-
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/