On Tue, Sep 10, 2013 at 6:27 PM, Tom Gundersen <teg@xxxxxxx> wrote: > On Tue, Sep 10, 2013 at 7:31 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> On Tue, 10 Sep 2013, Tom Gundersen wrote: >> >>> Hi Alan, >>> >>> On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >>> > On Tue, 10 Sep 2013, Tom Gundersen wrote: >>> > >>> >> Support for specifying soft dependencies in the modules themselves was >>> >> introduced in commit 7cb14ba. >>> >> >>> >> In Arch we have always been shipping a module.d(5) fragment ordering ohci/uhci >>> >> after ehci. If this ordering is really necessary, it would be great to move it >>> >> to the kernel and getting the correct fragment generated by depmod. >>> > >>> > The ordering is more of a recommendation than a necessity. Systems >>> > should work oksy if the modules are loaded in the wrong order. >>> > >>> > The only issue if the drivers are loaded in the wrong order is that >>> > full- and low-speed devices will end up being detected and enumerated >>> > twice, with a disconnection in between. This can result in >>> > disconcerting messages appearing in the system log. >>> > >>> > In theory, it is possible for a problem to arise. For example, suppose >>> > a full-speed flash drive is plugged in when the system starts up. >>> > When uhci-hcd or ohci-hcd gets loaded, the drive will be detected and >>> > it may even be mounted. Then when ehci-hcd loads, the drive will get >>> > disconnected and reconnected. Any open file references to the original >>> > mount will be orphaned. Then IMO it should not only be advised to have this dependency, but also require it. >>> >>> Thanks for the explanation. Sounds to me that a softdep is indeed appropriate: >>> >>> // >>> The softdep command allows you to specify soft, or optional, module >>> dependencies. modulename can be used without these optional modules Note that with this patch and another to kmod we are planning to change the behavior. It won't be optional anymore but required since depmod would then parse the modules.softdeps file and add them as dependencies automatically. >>> installed, but usually with some features missing. For example, a >>> driver for a storage HBA might require another module be loaded in >>> order to use management features. >>> >>> pre-deps and post-deps modules are lists of names and/or aliases of >>> other modules that modprobe will attempt to install (or remove) in >>> order before and after the main module given in the modulename >>> argument. >>> // >> >> So this means that before installing ohci-hcd, modprobe would attempt >> to install ehci-hcd? And if the attempt failed, it would go ahead and >> load ohci-hcd anyway? > > Exactly. Not really. If we try to load the module, but then fail we fail the operation altogether. Whereas if the module simply doesn't exist, then we carry on. In reality what we do is to assume the indexes and softdeps in configuration are correct) > >> What about during unloading? Would this mean that rmmod ohci-hcd would >> automatically cause ehci-hcd to be unloaded also? Or would unloading >> ehci-hcd cause ohci-hcd to be unloaded? > > No, unloading does not care about dependencies. modprobe -r will remove then as well, in the opposite order, i.e. post softdep, module, pre softdep. However this applies only to modprobe, not to the related function in libkmod since it would be weird to other programs using this library function. Try playing with this in /etc/modprobe.d/bla.conf (and replace echo with whatever unknown command to test a failure scenario): install bla echo install bla remove bla echo remove bla softdep sr_mod pre: bla Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
