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.
Signed-off-by: Tom Gundersen <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/ohci-hcd.c | 1 +
drivers/usb/host/uhci-hcd.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 8f6b695..783b50a 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1171,6 +1171,7 @@ EXPORT_SYMBOL_GPL(ohci_init_driver);
MODULE_AUTHOR (DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE ("GPL");
+MODULE_SOFTDEP("pre: ehci_hcd");
#if defined(CONFIG_ARCH_SA1100) && defined(CONFIG_SA1111)
#include "ohci-sa1111.c"
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 4a86b63..c2babf3 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -937,3 +937,4 @@ module_exit(uhci_hcd_cleanup);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: ehci_hcd");
--
1.8.4
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.
> Signed-off-by: Tom Gundersen <[email protected]>
> Cc: Alan Stern <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/usb/host/ohci-hcd.c | 1 +
> drivers/usb/host/uhci-hcd.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 8f6b695..783b50a 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1171,6 +1171,7 @@ EXPORT_SYMBOL_GPL(ohci_init_driver);
> MODULE_AUTHOR (DRIVER_AUTHOR);
> MODULE_DESCRIPTION(DRIVER_DESC);
> MODULE_LICENSE ("GPL");
> +MODULE_SOFTDEP("pre: ehci_hcd");
>
> #if defined(CONFIG_ARCH_SA1100) && defined(CONFIG_SA1111)
> #include "ohci-sa1111.c"
> diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
> index 4a86b63..c2babf3 100644
> --- a/drivers/usb/host/uhci-hcd.c
> +++ b/drivers/usb/host/uhci-hcd.c
> @@ -937,3 +937,4 @@ module_exit(uhci_hcd_cleanup);
> MODULE_AUTHOR(DRIVER_AUTHOR);
> MODULE_DESCRIPTION(DRIVER_DESC);
> MODULE_LICENSE("GPL");
> +MODULE_SOFTDEP("pre: ehci_hcd");
Where is MODULE_SOFTDEP defined? It isn't mentioned in any .h files in
my kernel tree.
Alan Stern
On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern <[email protected]> wrote:
> Where is MODULE_SOFTDEP defined? It isn't mentioned in any .h files in
> my kernel tree.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7cb14ba75d57910cc4b62115dd5db7bd83c93684
Kay
Hi Alan,
On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern <[email protected]> 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.
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
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.
//
>> Signed-off-by: Tom Gundersen <[email protected]>
>> Cc: Alan Stern <[email protected]>
>> Cc: Greg Kroah-Hartman <[email protected]>
>> ---
>> drivers/usb/host/ohci-hcd.c | 1 +
>> drivers/usb/host/uhci-hcd.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
>> index 8f6b695..783b50a 100644
>> --- a/drivers/usb/host/ohci-hcd.c
>> +++ b/drivers/usb/host/ohci-hcd.c
>> @@ -1171,6 +1171,7 @@ EXPORT_SYMBOL_GPL(ohci_init_driver);
>> MODULE_AUTHOR (DRIVER_AUTHOR);
>> MODULE_DESCRIPTION(DRIVER_DESC);
>> MODULE_LICENSE ("GPL");
>> +MODULE_SOFTDEP("pre: ehci_hcd");
>>
>> #if defined(CONFIG_ARCH_SA1100) && defined(CONFIG_SA1111)
>> #include "ohci-sa1111.c"
>> diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
>> index 4a86b63..c2babf3 100644
>> --- a/drivers/usb/host/uhci-hcd.c
>> +++ b/drivers/usb/host/uhci-hcd.c
>> @@ -937,3 +937,4 @@ module_exit(uhci_hcd_cleanup);
>> MODULE_AUTHOR(DRIVER_AUTHOR);
>> MODULE_DESCRIPTION(DRIVER_DESC);
>> MODULE_LICENSE("GPL");
>> +MODULE_SOFTDEP("pre: ehci_hcd");
>
> Where is MODULE_SOFTDEP defined? It isn't mentioned in any .h files in
> my kernel tree.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h#n104
Cheers,
Tom
On Tue, 10 Sep 2013, Tom Gundersen wrote:
> Hi Alan,
>
> On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern <[email protected]> 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.
>
> 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
> 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?
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?
> >> Signed-off-by: Tom Gundersen <[email protected]>
> >> Cc: Alan Stern <[email protected]>
> >> Cc: Greg Kroah-Hartman <[email protected]>
> >> ---
> >> drivers/usb/host/ohci-hcd.c | 1 +
> >> drivers/usb/host/uhci-hcd.c | 1 +
> >> 2 files changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> >> index 8f6b695..783b50a 100644
> >> --- a/drivers/usb/host/ohci-hcd.c
> >> +++ b/drivers/usb/host/ohci-hcd.c
> >> @@ -1171,6 +1171,7 @@ EXPORT_SYMBOL_GPL(ohci_init_driver);
> >> MODULE_AUTHOR (DRIVER_AUTHOR);
> >> MODULE_DESCRIPTION(DRIVER_DESC);
> >> MODULE_LICENSE ("GPL");
> >> +MODULE_SOFTDEP("pre: ehci_hcd");
> >>
> >> #if defined(CONFIG_ARCH_SA1100) && defined(CONFIG_SA1111)
> >> #include "ohci-sa1111.c"
> >> diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
> >> index 4a86b63..c2babf3 100644
> >> --- a/drivers/usb/host/uhci-hcd.c
> >> +++ b/drivers/usb/host/uhci-hcd.c
> >> @@ -937,3 +937,4 @@ module_exit(uhci_hcd_cleanup);
> >> MODULE_AUTHOR(DRIVER_AUTHOR);
> >> MODULE_DESCRIPTION(DRIVER_DESC);
> >> MODULE_LICENSE("GPL");
> >> +MODULE_SOFTDEP("pre: ehci_hcd");
> >
> > Where is MODULE_SOFTDEP defined? It isn't mentioned in any .h files in
> > my kernel tree.
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h#n104
I think I get the picture.
The MODULE_SOFTDEP lines should be moved to uhci-pci.c and ohci-pci.c,
because the ordering restrictions apply only to the PCI versions of
these drivers. And they should specify "pre: ehci-pci", not ehci-hcd.
Alan Stern
On Tue, Sep 10, 2013 at 7:31 PM, Alan Stern <[email protected]> wrote:
> On Tue, 10 Sep 2013, Tom Gundersen wrote:
>
>> Hi Alan,
>>
>> On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern <[email protected]> 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.
>>
>> 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
>> 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.
> 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.
>> >> Signed-off-by: Tom Gundersen <[email protected]>
>> >> Cc: Alan Stern <[email protected]>
>> >> Cc: Greg Kroah-Hartman <[email protected]>
>> >> ---
>> >> drivers/usb/host/ohci-hcd.c | 1 +
>> >> drivers/usb/host/uhci-hcd.c | 1 +
>> >> 2 files changed, 2 insertions(+)
>> >>
>> >> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
>> >> index 8f6b695..783b50a 100644
>> >> --- a/drivers/usb/host/ohci-hcd.c
>> >> +++ b/drivers/usb/host/ohci-hcd.c
>> >> @@ -1171,6 +1171,7 @@ EXPORT_SYMBOL_GPL(ohci_init_driver);
>> >> MODULE_AUTHOR (DRIVER_AUTHOR);
>> >> MODULE_DESCRIPTION(DRIVER_DESC);
>> >> MODULE_LICENSE ("GPL");
>> >> +MODULE_SOFTDEP("pre: ehci_hcd");
>> >>
>> >> #if defined(CONFIG_ARCH_SA1100) && defined(CONFIG_SA1111)
>> >> #include "ohci-sa1111.c"
>> >> diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
>> >> index 4a86b63..c2babf3 100644
>> >> --- a/drivers/usb/host/uhci-hcd.c
>> >> +++ b/drivers/usb/host/uhci-hcd.c
>> >> @@ -937,3 +937,4 @@ module_exit(uhci_hcd_cleanup);
>> >> MODULE_AUTHOR(DRIVER_AUTHOR);
>> >> MODULE_DESCRIPTION(DRIVER_DESC);
>> >> MODULE_LICENSE("GPL");
>> >> +MODULE_SOFTDEP("pre: ehci_hcd");
>> >
>> > Where is MODULE_SOFTDEP defined? It isn't mentioned in any .h files in
>> > my kernel tree.
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h#n104
>
> I think I get the picture.
>
> The MODULE_SOFTDEP lines should be moved to uhci-pci.c and ohci-pci.c,
> because the ordering restrictions apply only to the PCI versions of
> these drivers. And they should specify "pre: ehci-pci", not ehci-hcd.
Thanks, I'll send a new patch.
-t
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.
Signed-off-by: Tom Gundersen <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
---
v2: change the dependencies to *_pci, as suggested by Alan
drivers/usb/host/ohci-pci.c | 1 +
drivers/usb/host/uhci-pci.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index ec337c2..eedf97c 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -323,3 +323,4 @@ module_exit(ohci_pci_cleanup);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: ehci_pci");
diff --git a/drivers/usb/host/uhci-pci.c b/drivers/usb/host/uhci-pci.c
index c300bd2f7..f7bbf43 100644
--- a/drivers/usb/host/uhci-pci.c
+++ b/drivers/usb/host/uhci-pci.c
@@ -299,3 +299,5 @@ static struct pci_driver uhci_pci_driver = {
},
#endif
};
+
+MODULE_SOFTDEP("pre: ehci_pci");
--
1.8.4
Hello.
On 09/11/2013 01:30 AM, Tom Gundersen wrote:
> Support for specifying soft dependencies in the modules themselves was
> introduced in commit 7cb14ba.
Please also specify that commit's summary line in parens.
> 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.
> Signed-off-by: Tom Gundersen <[email protected]>
> Cc: Alan Stern <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
WBR, Sergei
On Tue, Sep 10, 2013 at 6:27 PM, Tom Gundersen <[email protected]> wrote:
> On Tue, Sep 10, 2013 at 7:31 PM, Alan Stern <[email protected]> wrote:
>> On Tue, 10 Sep 2013, Tom Gundersen wrote:
>>
>>> Hi Alan,
>>>
>>> On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern <[email protected]> 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
On Tue, 10 Sep 2013, Lucas De Marchi wrote:
> >>> > 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.
Requiring the ordering won't fix all the possible problems. For
example, ehci-pci might be compiled into the kernel while ohci-pci is
built as a module (although this probably could be prevented by
tweaking the Kconfig file).
> >> 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 if somebody really does want to load ohci-pci without loading
ehci-pci? That is a perfectly valid thing to do (and I often want to
do it for testing).
It sounds like the only way to accomplish this would be to load both
and then unload ehci-pci. Yes? Or would that unload ohci-pci as well?
> >> 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.
Aside from testing, people hardly ever unload drivers. So this is a
relatively minor concern.
> 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
Good recommendation.
Alan Stern