Hi Tejun, On Sat, Sep 06, 2014 at 07:55:33AM +0900, Tejun Heo wrote: > Hello, Dmitry. > > On Fri, Sep 05, 2014 at 03:49:17PM -0700, Dmitry Torokhov wrote: > > 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. > > I don't get it. This is a behavior userland already depends on for > boots. What's there to agree or disagree? This is just a fact that > we can't do this w/o disturbing some userlands in a major way. I am just expressing my disbelief that somebody relies on module loading being synchronous with probing. Out of curiosity, do you have any pointers? > > > 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). > > This sure can be worked around from userland side too by not imposing > any timeout on module loading but that said for the same reasons that > you've been arguing until now, I actually do think that it's kinda > silly to make device probing synchronous to module loading at this > time and age. What we disagree on is not that we want to separate > those waits. It is about how to achieve it. Well, there are separate things we want to solve. My main issue is not with modules, but rather compiled-in drivers that stall kernel boot, and these particular drivers are just fine if they are probed out of bound. > > > > 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. > > It's a different shitstorm where we actively break bootings on some > userlands. Trust me. That's gonna be a lot worse. That did break bootings and that's why we reverted the wholesale async probing. 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
