Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support
From: Greg KH <gregkh@linuxfoundation.org>
Date: 2014-09-29 22:00:45
Also in:
linux-scsi, lkml
On Mon, Sep 29, 2014 at 11:22:08PM +0200, Luis R. Rodriguez wrote:
On Sun, Sep 28, 2014 at 11:03:29AM -0400, Tejun Heo wrote:quoted
Hello, On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote: ...quoted
Systemd should consider enabling async probe on device drivers it loads through systemd-udev but probably does not want to enable it for modules loaded through systemd-modules-load (modules-load.d). At least on my booting enablign async probe for all modules fails to boot as such in order to make thisDid you find out why boot failed with those modules?No, it seems this was early in boot and I haven't been able to capture the logs yet of the faults. More on this below.quoted
quoted
a bit more useful we whitelist a few buses where it should be at least in theory safe to try to enable async probe. This way even if systemd tried to ask to enable async probe for all its device drivers the kernel won't blindly do this. We also have the sync_probe flag which device drivers can themselves enable *iff* its known the device driver should never async probe. In order to help *test* things folks can use the bus.safe_mod_async_probe=1 kernel parameter which will work as if userspace would have requested all modules to load with async probe. Daring folks can also use bus.force_mod_async_probe=1 which will enable asynch probe even on buses not tested in any way yet, if you use that though you're on your own.If those two knobs are meant for debugging, let's please make that fact immediately evident. e.g. Make them ugly boot params like "__DEVEL__driver_force_mod_async_probe". Devel/debug options ending up becoming stable interface are really nasty.Sure make sense, I wasn't quite sure how to make this quite clear, a naming convention seems good to me but I also had added at least a print about this on the log. Ideally I think a TAIN_DEBUG would be best and it seems it could be useful for many other cases in the kernel, we could also just re-use TAINT_CRAP as well. Thoughts? Greg?
TAINT_CRAP is for drivers/staging/ code, don't try to repurpose it for some other horrid option. There's no reason we can't add more taint flags for this. greg k-h