On Wed, Mar 13, 2013 at 08:35:02AM -0500, Mark Hatle wrote: > On 3/13/13 8:07 AM, Bruce Ashfield wrote: > > On Tue, Mar 12, 2013 at 5:32 PM, Mark Hatle <[email protected]> > > wrote: > >> I have someone who is trying to use update-alternatives with kernel > >> modules. > >> > >> They discovered that the rename code changes the name of the module to end > >> in .ko.${BPN}. While the package.bbclass code specifically looks for the > >> file name to end in '.ko' in order to avoid stripping the modules... so of > >> course the modules get stripped and no longer work properly. > >> > >> So my question is, is it even reasonable to use update-alternatives with > >> kernel modules? If it is, we probably need to change the trigger in > >> packages.bbclass to look for either .ko or .ko.${BPN} (or something > >> similar). > >> > >> Any comments/suggestions? > > > > I'm having a hard time wrapping my head around what they are trying > > to achieve. Can you describe it from a non-packaging point of view ? > > > > i.e. do they have two kernel modules that provide the same sort of > > services to the kernel and they want to switch between the two of > > them based on the alternatives mechanism ? > > Yes, that is exactly it. For some reason they have two kernel modules that > have > the same name, same external behavior.. but internally there are code > changes. > Using the update-alternatives mechanism they have selected one version is > "better" then the other. > > (Frankly this seems bogus to me.. which is why I'm asking the question. Is > this > even supported or is this simply "don't do that".)
Cannot you rename them in do_install to module-foo.${BPN}.ko and set
ALTERNATIVE_TARGET_kernel-module-foo[foo] to module-foo.${BPN}.ko ?
--
Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
