Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers

[Dan Williams]

On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> wrote:
> Some devices take a long time when initializing, and not all drivers are
> suited to initialize their devices when they are open. For example,
> input drivers need to interrogate their devices in order to publish
> device's capabilities before userspace will open them. When such drivers
> are compiled into kernel they may stall entire kernel initialization.
>
> This change allows drivers request for their probe functions to be
> called asynchronously during driver and device registration (manual
> binding is still synchronous). Because async_schedule is used to perform
> asynchronous calls module loading will still wait for the probing to
> complete.
>
> Note that the end goal is to make the probing asynchronous by default,
> so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary
> measure that allows us to speed up boot process while we validating and
> fixing the rest of the drivers and preparing userspace.
>
> This change is based on earlier patch by "Luis R. Rodriguez"
> <mcgrof@xxxxxxxx>
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
> ---
>  drivers/base/base.h    |   1 +
>  drivers/base/bus.c     |  31 +++++++---
>  drivers/base/dd.c      | 149 ++++++++++++++++++++++++++++++++++++++++++-------
>  include/linux/device.h |  28 ++++++++++
>  4 files changed, 182 insertions(+), 27 deletions(-)

Just noticed this patch.  It caught my eye because I had a hard time
getting an open coded implementation of asynchronous probing to work
in the new libnvdimm subsystem.  Especially the messy races of tearing
things down while probing is still in flight.  I ended up implementing
asynchronous device registration which eliminated a lot of complexity
and of course the bugs.  In general I tend to think that async
registration is less risky than async probe since it keeps wider
portions of the traditional device model synchronous and leverages the
fact that the device model is already well prepared for asynchronous
arrival of devices due to hotplug.  Splitting the "initial probe" from
the "manual probe" case seems like a recipe for confusion.
--
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/