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: > > Hello, > > > > On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote: > > ... > > > 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 this > > > > Did 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. > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
