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".)
--Mark
Cheers,
Bruce
--Mark
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
