On Sat, Sep 06, 2014 at 07:31:39AM +0900, Tejun Heo wrote: > On Sat, Sep 06, 2014 at 07:29:56AM +0900, Tejun Heo wrote: > > It is for storage devices which always have guaranteed synchronous > > probing on module load and well-defined probing order. Agree about probing order (IIRC that is why we had to revert the wholesale asynchronous probing a few years back) but totally disagree about synchronous module loading. Anyway, I just posted a patch that I think preserves module loading behavior and solves my issue with built-in modules. It does not help Luis' issue though (but then I think the main problem is with systemd being stupid there). > > Sure, modern > > setups are a lot more dynamic but I'm quite certain that there are > > setups in the wild which depend on storage driver loading being > > synchronous. We can't simply declare one day that such behavior is > > broken and break, most likely, their boots. > > To add a bit, if the argument here is that dependency on such behavior > shouldn't exist and module loading and device probing should always be > asynchronous, the right approach is implementing "synchronous_probing" > flag not the other way around. I actually wouldn't hate to see that > change happening but whoever submits and routes such a change should > be ready for a major shitstorm, I'm afraid. I think we already had this storm and that is why here we have opt-in behavior for the drivers. Thanks. -- Dmitry -- 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
