linux-kernel - Re: [PATCH] drivercore: Add driver probe deferral mechanism

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAPXgP11wKfp7CMuXpoensQ9ey+CeH86h6KT3aW5NrQx1WZaWHg@mail.gmail.com>
Date:	Sun, 10 Jul 2011 16:24:12 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Greg KH <gregkh@...e.de>, Arnd Bergmann <arnd@...db.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] drivercore: Add driver probe deferral mechanism

On Tue, Jul 5, 2011 at 18:28, Grant Likely <grant.likely@...retlab.ca> wrote:
> On Tue, Jul 5, 2011 at 10:11 AM, Kay Sievers <kay.sievers@...y.org> wrote:
>> On Tue, Jul 5, 2011 at 17:50, Greg KH <gregkh@...e.de> wrote:
>>
>>> I wonder if doing this all from a workqueue in the first place is going
>>> to cause problems as probe isn't normally done this way at all.
>>
>> Yeah, I would expect unforeseen problems with the async thread too.
>> It's probably all solvable, but it sounds troublesome to find out if
>> things go wrong.
>>
>> We have sync hooks (BUS_NOTIFY_*) where any kind of code can subscribe
>> to when devices get added or get bound to a driver. Can't the code
>> that relies on later hookups to already existing devices/bindings not
>> just plug into that?
>
> I tried that.  It resulted in a lot of complexity that each driver
> needs to implement correctly which is why I started looking for a
> different way to go about it.

What I mean is that we might not necessarily need to have that in
'struct device' and the driver-binding code. Can't we just allocate
the reprobe-in-the-back logic in its own object, let this object hook
into the existing notifier chain (if needed add more notifiers) and
have your reprobe object itself check for the device, carry its own
list of devices and trigger the needed work?

(As a general note, not specifically related to this patch: The
current 'struct device' is a total mess already, and really needs to
be cleaned up. The list.h way of doing lists might perform nice in
some always-be-a-list-member used cases, but it is really not the
appropriate way of doing non-common functionality on common objects:
performance does not matter at all here, and the object-to-add itself
has to carry the list-data needed for every non-common list.)

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