* update-alternatives and kernel modules
@ 2013-03-12 22:32 Mark Hatle
2013-03-13 13:07 ` Bruce Ashfield
0 siblings, 1 reply; 5+ messages in thread
From: Mark Hatle @ 2013-03-12 22:32 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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?
--Mark
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: update-alternatives and kernel modules
2013-03-12 22:32 update-alternatives and kernel modules Mark Hatle
@ 2013-03-13 13:07 ` Bruce Ashfield
2013-03-13 13:35 ` Mark Hatle
0 siblings, 1 reply; 5+ messages in thread
From: Bruce Ashfield @ 2013-03-13 13:07 UTC (permalink / raw)
To: Mark Hatle; +Cc: Patches and discussions about the oe-core layer
On Tue, Mar 12, 2013 at 5:32 PM, Mark Hatle <mark.hatle@windriver.com> 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 ?
Cheers,
Bruce
> --Mark
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: update-alternatives and kernel modules
2013-03-13 13:07 ` Bruce Ashfield
@ 2013-03-13 13:35 ` Mark Hatle
2013-03-13 13:48 ` Martin Jansa
0 siblings, 1 reply; 5+ messages in thread
From: Mark Hatle @ 2013-03-13 13:35 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer
On 3/13/13 8:07 AM, Bruce Ashfield wrote:
> On Tue, Mar 12, 2013 at 5:32 PM, Mark Hatle <mark.hatle@windriver.com> 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
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: update-alternatives and kernel modules
2013-03-13 13:35 ` Mark Hatle
@ 2013-03-13 13:48 ` Martin Jansa
2013-03-13 15:05 ` Mark Hatle
0 siblings, 1 reply; 5+ messages in thread
From: Martin Jansa @ 2013-03-13 13:48 UTC (permalink / raw)
To: Mark Hatle; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]
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 <mark.hatle@windriver.com> 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: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: update-alternatives and kernel modules
2013-03-13 13:48 ` Martin Jansa
@ 2013-03-13 15:05 ` Mark Hatle
0 siblings, 0 replies; 5+ messages in thread
From: Mark Hatle @ 2013-03-13 15:05 UTC (permalink / raw)
To: Martin Jansa; +Cc: Patches, the oe-core layer
On 3/13/13 8:48 AM, Martin Jansa wrote:
> 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 <mark.hatle@windriver.com> 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 ?
My understanding (perhaps incorrect) is that depmod uses the ".ko" extension to
figure out what to process and what to load. By having them all end in ".ko",
it's going to affect automatic loading and you could get either one (or neither)
to load properly.
But that was a suggestion I had originally thought of. I'm still wondering
though if this whole premise is simply wrong.
--Mark
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-03-13 15:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-12 22:32 update-alternatives and kernel modules Mark Hatle
2013-03-13 13:07 ` Bruce Ashfield
2013-03-13 13:35 ` Mark Hatle
2013-03-13 13:48 ` Martin Jansa
2013-03-13 15:05 ` Mark Hatle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox