On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez <mcg...@do-not-panic.com> wrote: > On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen <t...@jklm.no> wrote: >> How about simply introducing a new flag to finit_module() to indicate >> that the caller does not care about asynchronicity. We could then pass >> this from udev, but existing scripts calling modprobe/insmod will not >> be affected. > > Do you mean that you *do want asynchronicity*?
Precisely, udev would opt-in, but existing scripts etc would not. >> But isn't finit_module() taking a long time a serious problem given >> that it means no other module can be loaded in parallel? > > Indeed but having a desire to make the init() complete fast is > different than the desire to have the combination of both init and > probe fast synchronously. I guess no one is arguing that probe should somehow be required to be fast, but rather: > If userspace wants init to be fast and let > probe be async then userspace has no option but to deal with the fact > that async probe will be async, and it should then use other methods > to match any dependencies if its doing that itself. Correct. And this therefore likely needs to be opt-in behaviour per finit_module() invocation to avoid breaking old assumptions. > For example > networking should not kick off after a network driver is loaded but > rather one the device creeps up on udev. We should be good with > networking dealing with this correctly today but not sure about other > subsystems. depmod should be able to load the required modules in > order and if bus drivers work right then probe of the remnant devices > should happen asynchronously. The one case I can think of that is a > bit different is modules-load.d things but those *do not rely on the > timeout*, but are loaded prior to a service requirement. Note though > that if those modules had probe and they then run async'd then systemd > service would probably need to consider that the requirements may not > be there until later. If this is not carefully considered that could > introduce regression to users of modules-load.d when async probe is > fully deployed. The same applies to systemd making assumptions of kmod > loading a module and a dependency being complete as probe would have > run it before. Yeah, these all needs to be considered when deciding whether or not to enable async in each specific case. > I believe one concern here lies in on whether or not userspace > is properly equipped to deal with the requirements on module loading > doing async probing and that possibly failing. Perhaps systemd might > think all userspace is ready for that but are we sure that's the case? There almost certainly are custom things out there relying on the synchronous behaviour, but if we make it opt-in we should not have a problem. Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
