[Bug 627] modprobe-small: incorrect alias-based probe with dep_bb_fd < 0

bugzilla at busybox.net bugzilla at busybox.net
Thu Oct 1 08:04:02 UTC 2009


--- Comment #16 from Jiri J. <jirij.jabb at gmail.com>  2009-10-01 08:03:58 UTC ---
(In reply to comment #15)
> Is the *order* in which they are insmod'ed matches modules.alias order?
I believe so. Their order seems to be shifted in lsmod output.

> I guess if ata_generic is insmod'ed first, it will "take" the device, and later
> ata_piix will just hang around, with no devices to handle.
I wouldn't say that. I can freely modprobe ata_generic (by hand) before
modprobing ata_piix and it won't hurt anything. I guess ata_generic won't even
recognize it.
However, you're right that ata_generic might take over it in other cases,
that's why some people had to blacklist ata_generic on their desktop machines
to get the maximum speed benefit.

> This may be a satisfactory outcome, though... would it be satisfactory for you?
As for me, I'm going to use the normal module-init-tools. I've several reasons
for that, like nice lsmod output, blacklist support, squashfs-compressed
modules.* files are almost the same size as compressed modules.dep.bb (~900
bytes), rmmod isn't recursively removing modules and so on. It isn't going to
be really embedded OS, users will need to interact with it using the ash shell,
so I'm with the more user-friendly way, even if it adds ~1K to the binary.

My opinion is that the "simplified modutils" should be used mainly on the
embedded devices, where the manufacturer can simply put modprobes in an startup
script (since he knows the exact hardware) without the need of using some kind
of uevent probing script.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the busybox-cvs mailing list