Am Montag, den 06.05.2013, 12:59 -0300 schrieb Lucas De Marchi: > Hi Stefan, > > On Sun, May 5, 2013 at 11:55 AM, Stefan Achatz <stefan_achatz@xxxxxx> wrote: > > Hello, > > > > I'm writing kernel modules for usb peripheries that are in mainline kernel and > > also available as external compileable package[1]. > > > > The external modules have the newest code before it gets into the next kernel, > > also backported for older kernels. To distinguish between outdated kernel > > included and newer external modules they have different names. The device > > specific kernel internal modules are called hid-roccat-* whereas the external > > ones are called just *. This way a blacklist can prohibit loading the internal > > modules when the external are installed. > > Since depmod (both from kmod and module-init-tools) doesn't know > anything about blacklists it can't rely on this existing so to not > creating "invalid" indexes. > > Taking a look on our current implementation, it looks like we fail on > warning about duplicate symbols while inserting them on hash table to > calculate the dependencies. I guess this only worked for you on > module-init-tools by luck since its hash table allows duplicate > entries, but then on lookup you will get the first one, depending on > the order in which they were inserted. IMO it seems a very weak > guarantee on which module will get. > > > > > > Nevertheless, having both, internal and external, modules installed leads to > > double symbols. depmod from module-init-tools has no problem with that (some > > of the last versions tested), where the variant from kmod has its problem (v5 > > up to v12 tested). I observed this using Fedora 18, which seems to be the first > > distro that uses kmods depmod. > > > > Some outputs of both depmods for comparison are further down this text. > > > > My question: Should this behaviour be fixed in kmods depmod, or is there a > > intended, perhaps more intelligent, way for me to do what I intend? > > I'd propose you check if the following scheme fits your needs: > > 1) change the external modules to have the same names as the internal ones > 2) install a file under /usr/lib/depmod.d/module-name.conf containing > an "override" line - see depmod.d(5) > or > 2a) Use a .conf file with "search" keyword, ensuring its priority is > higher than the standard ones I chose the override method and got no complaints from users so far. DKMS doesn't even need the config file since it ensures uniqueness itself by moving the original modules to a backup location if the modules have the same names. Thanks for helping Stefan -- 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
