| Message ID | 20230104121808.1065203-3-toertel@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Load proper sound drivers for QEMU x86 | expand |
On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas <toertel@gmail.com> wrote: > > From: Mark Jonas <toertel@gmail.com> > > If DISTRO_FEATURES includes ALSA then automatically load the > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the > machine configurations conf/machine/qemux86.conf and qemux86-64.conf. > > Signed-off-by: Mark Jonas <toertel@gmail.com> > --- > meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > index 091003ed82..c8a9b0a1e3 100644 > --- a/meta/recipes-kernel/linux/linux-yocto.inc > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" > > +# sound driver recommended by conf/machine/qemux86*.conf > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" This gets us most of the way, but if we are going to do this we should complete the job. We really need to make sure there's a configuration fragment that explicitly enables the modules we need (and not count on defaults, or other selects). That would go into the kernel-cache. It would then be something we'd add to the KERNEL_FEATRES triggered off the distro feature. Just like we are doing with numa and vfat that is visible in the context of the patch. Bruce > + > # A KMACHINE is the mapping of a yocto $MACHINE to what is built > # by the kernel. This is typically the branch that should be built, > # and it can be specific to the machine or shared > -- > 2.34.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#175471): https://lists.openembedded.org/g/openembedded-core/message/175471 > Mute This Topic: https://lists.openembedded.org/mt/96048827/1050810 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
Hi Bruce, On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas <toertel@gmail.com> wrote: > > > > From: Mark Jonas <toertel@gmail.com> > > > > If DISTRO_FEATURES includes ALSA then automatically load the > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the > > machine configurations conf/machine/qemux86.conf and qemux86-64.conf. > > > > Signed-off-by: Mark Jonas <toertel@gmail.com> > > --- > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > > index 091003ed82..c8a9b0a1e3 100644 > > --- a/meta/recipes-kernel/linux/linux-yocto.inc > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" > > > > +# sound driver recommended by conf/machine/qemux86*.conf > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" > > This gets us most of the way, but if we are going to do this we should > complete the job. > > We really need to make sure there's a configuration fragment that > explicitly enables > the modules we need (and not count on defaults, or other selects). That would go > into the kernel-cache. > > It would then be something we'd add to the KERNEL_FEATRES triggered off the > distro feature. Just like we are doing with numa and vfat that is visible in the > context of the patch. In my understanding this is already the case. See for example linux-yocto_5.19.bb which contains the following lines. KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD into the same file where the corresponding configuration fragment is added? But that would mean to duplicate the lines over five recipes. Alternatively I could move the cfg/sound.scc out of the recipes into the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also get it. Cheers, Mark
On Thu, Jan 5, 2023 at 8:42 AM Mark Jonas <toertel@gmail.com> wrote: > > Hi Bruce, > > On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > From: Mark Jonas <toertel@gmail.com> > > > > > > If DISTRO_FEATURES includes ALSA then automatically load the > > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the > > > machine configurations conf/machine/qemux86.conf and qemux86-64.conf. > > > > > > Signed-off-by: Mark Jonas <toertel@gmail.com> > > > --- > > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > > > index 091003ed82..c8a9b0a1e3 100644 > > > --- a/meta/recipes-kernel/linux/linux-yocto.inc > > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" > > > > > > +# sound driver recommended by conf/machine/qemux86*.conf > > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" > > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" > > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" > > > > This gets us most of the way, but if we are going to do this we should > > complete the job. > > > > We really need to make sure there's a configuration fragment that > > explicitly enables > > the modules we need (and not count on defaults, or other selects). That would go > > into the kernel-cache. > > > > It would then be something we'd add to the KERNEL_FEATRES triggered off the > > distro feature. Just like we are doing with numa and vfat that is visible in the > > context of the patch. > > In my understanding this is already the case. See for example > linux-yocto_5.19.bb which contains the following lines. > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD > into the same file where the corresponding configuration fragment is > added? But that would mean to duplicate the lines over five recipes. > > Alternatively I could move the cfg/sound.scc out of the recipes into > the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also > get it. I definitely wasn't clear. Sorry about that, I'm still partially on holidays and didn't have enough coffee when I wrote that. That is close to what I meant. It is one thing to define the options in our generic sound "buckets" and another to put a specific module into the autoload. If we are going to autoload a module, the option really should be pulled out of the generic bucket, and put into something smaller / specific to what we are trying to do, and trigger the inclusion of that fragment only when the appropriate distro feature is set. The machine conf files specifying specific modules isn't ideal, since it is largely "aspirational" unless it is coupled with a KERNEL_FEATURE that is set based on a machine or distro feature. If you search the mailing list archives, you'll see me musing about how I need to change those unconditional appends of option to qemu, as it makes defining a new qemu machine problematic (if the options are causing issues). The tweak I'm describing is a small step in that direction. One new question comes to mind, what init system were you testing with (default poky and sysvinit ?) ? If we now have the proper init system, are no events being triggered to load the modules now that the proper ones are in the machine files ? Bruce > > Cheers, > Mark -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
Hi Bruce, On Thu, Jan 5, 2023 at 3:57 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Thu, Jan 5, 2023 at 8:42 AM Mark Jonas <toertel@gmail.com> wrote: > > > > Hi Bruce, > > > > On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > > > From: Mark Jonas <toertel@gmail.com> > > > > > > > > If DISTRO_FEATURES includes ALSA then automatically load the > > > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the > > > > machine configurations conf/machine/qemux86.conf and qemux86-64.conf. > > > > > > > > Signed-off-by: Mark Jonas <toertel@gmail.com> > > > > --- > > > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++ > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > > > > index 091003ed82..c8a9b0a1e3 100644 > > > > --- a/meta/recipes-kernel/linux/linux-yocto.inc > > > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > > > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" > > > > > > > > +# sound driver recommended by conf/machine/qemux86*.conf > > > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" > > > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" > > > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" > > > > > > This gets us most of the way, but if we are going to do this we should > > > complete the job. > > > > > > We really need to make sure there's a configuration fragment that > > > explicitly enables > > > the modules we need (and not count on defaults, or other selects). That would go > > > into the kernel-cache. > > > > > > It would then be something we'd add to the KERNEL_FEATRES triggered off the > > > distro feature. Just like we are doing with numa and vfat that is visible in the > > > context of the patch. > > > > In my understanding this is already the case. See for example > > linux-yocto_5.19.bb which contains the following lines. > > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD > > into the same file where the corresponding configuration fragment is > > added? But that would mean to duplicate the lines over five recipes. > > > > Alternatively I could move the cfg/sound.scc out of the recipes into > > the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also > > get it. > > I definitely wasn't clear. Sorry about that, I'm still partially on > holidays and didn't have enough coffee when I wrote that. > > That is close to what I meant. It is one thing to define the options > in our generic sound "buckets" and another to put a specific module > into the autoload. > > If we are going to autoload a module, the option really should be > pulled out of the generic bucket, and put into something smaller / > specific to what we are trying to do, and trigger the inclusion of > that fragment only when the appropriate distro feature is set. The > machine conf files specifying specific modules isn't ideal, since it > is largely "aspirational" unless it is coupled with a KERNEL_FEATURE > that is set based on a machine or distro feature. I have to admit that I feel a bit lost. I am not really sure I understood what you meant. Is the "generic bucket" cfg/sound.scc? But why should we break that up? A module only ends up in an image if the module is installed. And the installation is controlled e.g. by MACHINE_EXTRA_RRECOMMENDS in the machine file. > If you search the mailing list archives, you'll see me musing about > how I need to change those unconditional appends of option to qemu, as > it makes defining a new qemu machine problematic (if the options are > causing issues). The tweak I'm describing is a small step in that > direction. What I understood is that you propose to change the existing KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" in e.g. linux-yocto_5.19.bb to (remove cfg/sound.scc) KERNEL_FEATURES:append:qemux86=" cfg/paravirt_kvm.scc" KERNEL_FEATURES:append:qemux86-64=" cfg/paravirt_kvm.scc" and add (move) the following into linux-yocto.inc KERNEL_FEATURES:append:qemuall=" ${@bb.utils.contains('MACHINE_FEATURES', 'alsa', 'cfg/sound.scc', '', d)}" That is, instead of coupling the compilation of QEMU sound driver modules based on machine name qemux86 and qemux86-64 we activate it for all QEMU machines which also have alsa as a MACHINE_FEATURE. And that is set in machine/include/qemu.inc. > One new question comes to mind, what init system were you testing with > (default poky and sysvinit ?) ? If we now have the proper init system, > are no events being triggered to load the modules now that the proper > ones are in the machine files ? I was testing on Poky with the default init system i.e, sysvinit. Without the KERNEL_MODULE_AUTOLOAD line the snd-intel8x0 module is not loaded. And it seems you are right: The KERNEL_MODULE_AUTOLOAD is superfluous. Even when I remove the second patch the modules are still loaded. I am a little puzzled why it originally seemed to me that it was necessary. Cheers, Mark
On Fri, 2023-01-06 at 11:13 +0100, Mark Jonas wrote: > Hi Bruce, > > On Thu, Jan 5, 2023 at 3:57 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > On Thu, Jan 5, 2023 at 8:42 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > Hi Bruce, > > > > > > On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > > > > > From: Mark Jonas <toertel@gmail.com> > > > > > > > > > > If DISTRO_FEATURES includes ALSA then automatically load the > > > > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the > > > > > machine configurations conf/machine/qemux86.conf and qemux86-64.conf. > > > > > > > > > > Signed-off-by: Mark Jonas <toertel@gmail.com> > > > > > --- > > > > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++ > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > index 091003ed82..c8a9b0a1e3 100644 > > > > > --- a/meta/recipes-kernel/linux/linux-yocto.inc > > > > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" > > > > > > > > > > +# sound driver recommended by conf/machine/qemux86*.conf > > > > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" > > > > > > > > This gets us most of the way, but if we are going to do this we should > > > > complete the job. > > > > > > > > We really need to make sure there's a configuration fragment that > > > > explicitly enables > > > > the modules we need (and not count on defaults, or other selects). That would go > > > > into the kernel-cache. > > > > > > > > It would then be something we'd add to the KERNEL_FEATRES triggered off the > > > > distro feature. Just like we are doing with numa and vfat that is visible in the > > > > context of the patch. > > > > > > In my understanding this is already the case. See for example > > > linux-yocto_5.19.bb which contains the following lines. > > > > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > > > Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD > > > into the same file where the corresponding configuration fragment is > > > added? But that would mean to duplicate the lines over five recipes. > > > > > > Alternatively I could move the cfg/sound.scc out of the recipes into > > > the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also > > > get it. > > > > I definitely wasn't clear. Sorry about that, I'm still partially on > > holidays and didn't have enough coffee when I wrote that. > > > > That is close to what I meant. It is one thing to define the options > > in our generic sound "buckets" and another to put a specific module > > into the autoload. > > > > If we are going to autoload a module, the option really should be > > pulled out of the generic bucket, and put into something smaller / > > specific to what we are trying to do, and trigger the inclusion of > > that fragment only when the appropriate distro feature is set. The > > machine conf files specifying specific modules isn't ideal, since it > > is largely "aspirational" unless it is coupled with a KERNEL_FEATURE > > that is set based on a machine or distro feature. > > I have to admit that I feel a bit lost. I am not really sure I > understood what you meant. > > Is the "generic bucket" cfg/sound.scc? But why should we break that > up? A module only ends up in an image if the module is installed. And > the installation is controlled e.g. by MACHINE_EXTRA_RRECOMMENDS in > the machine file. I might also be misunderstanding but I think what Bruce is asking is that the qemux86 sound pieces be broken out of cfg/sound.scc. In case you didn't find them, the files are here: https://git.yoctoproject.org/yocto-kernel-cache/tree/cfg/sound.scc https://git.yoctoproject.org/yocto-kernel-cache/tree/cfg/sound.cfg and the question is which of the options in sound.cfg are the drivers which qemu needs on x86. I think Bruce would like a patch which splits those items out and triggers them on qemux86 specifically. This means if things change in future, we know exactly which module options we need for sound on qemux86. Bruce can correct me if I misunderstand! :) > > If you search the mailing list archives, you'll see me musing about > > how I need to change those unconditional appends of option to qemu, as > > it makes defining a new qemu machine problematic (if the options are > > causing issues). The tweak I'm describing is a small step in that > > direction. > > What I understood is that you propose to change the existing > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > in e.g. linux-yocto_5.19.bb to (remove cfg/sound.scc) > > KERNEL_FEATURES:append:qemux86=" cfg/paravirt_kvm.scc" > KERNEL_FEATURES:append:qemux86-64=" cfg/paravirt_kvm.scc" > > and add (move) the following into linux-yocto.inc > > KERNEL_FEATURES:append:qemuall=" > ${@bb.utils.contains('MACHINE_FEATURES', 'alsa', 'cfg/sound.scc', '', > d)}" > > That is, instead of coupling the compilation of QEMU sound driver > modules based on machine name qemux86 and qemux86-64 we activate it > for all QEMU machines which also have alsa as a MACHINE_FEATURE. And > that is set in machine/include/qemu.inc. > > > One new question comes to mind, what init system were you testing with > > (default poky and sysvinit ?) ? If we now have the proper init system, > > are no events being triggered to load the modules now that the proper > > ones are in the machine files ? > > I was testing on Poky with the default init system i.e, sysvinit. > Without the KERNEL_MODULE_AUTOLOAD line the snd-intel8x0 module is not > loaded. > > And it seems you are right: The KERNEL_MODULE_AUTOLOAD is superfluous. > Even when I remove the second patch the modules are still loaded. I am > a little puzzled why it originally seemed to me that it was necessary. I'm not sure on that. The kernel will try and autoprobe for drivers for hardware it has present where it can though. Cheers, Richard
Hi Richard and Bruce, On Fri, Jan 6, 2023 at 12:27 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Fri, 2023-01-06 at 11:13 +0100, Mark Jonas wrote: > > Hi Bruce, > > > > On Thu, Jan 5, 2023 at 3:57 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > On Thu, Jan 5, 2023 at 8:42 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > > > Hi Bruce, > > > > > > > > On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > > > > > > > From: Mark Jonas <toertel@gmail.com> > > > > > > > > > > > > If DISTRO_FEATURES includes ALSA then automatically load the > > > > > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the > > > > > > machine configurations conf/machine/qemux86.conf and qemux86-64.conf. > > > > > > > > > > > > Signed-off-by: Mark Jonas <toertel@gmail.com> > > > > > > --- > > > > > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++ > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > > index 091003ed82..c8a9b0a1e3 100644 > > > > > > --- a/meta/recipes-kernel/linux/linux-yocto.inc > > > > > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ > > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" > > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" > > > > > > > > > > > > +# sound driver recommended by conf/machine/qemux86*.conf > > > > > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" > > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" > > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" > > > > > > > > > > This gets us most of the way, but if we are going to do this we should > > > > > complete the job. > > > > > > > > > > We really need to make sure there's a configuration fragment that > > > > > explicitly enables > > > > > the modules we need (and not count on defaults, or other selects). That would go > > > > > into the kernel-cache. > > > > > > > > > > It would then be something we'd add to the KERNEL_FEATRES triggered off the > > > > > distro feature. Just like we are doing with numa and vfat that is visible in the > > > > > context of the patch. > > > > > > > > In my understanding this is already the case. See for example > > > > linux-yocto_5.19.bb which contains the following lines. > > > > > > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > > > > > Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD > > > > into the same file where the corresponding configuration fragment is > > > > added? But that would mean to duplicate the lines over five recipes. > > > > > > > > Alternatively I could move the cfg/sound.scc out of the recipes into > > > > the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also > > > > get it. > > > > > > I definitely wasn't clear. Sorry about that, I'm still partially on > > > holidays and didn't have enough coffee when I wrote that. > > > > > > That is close to what I meant. It is one thing to define the options > > > in our generic sound "buckets" and another to put a specific module > > > into the autoload. > > > > > > If we are going to autoload a module, the option really should be > > > pulled out of the generic bucket, and put into something smaller / > > > specific to what we are trying to do, and trigger the inclusion of > > > that fragment only when the appropriate distro feature is set. The > > > machine conf files specifying specific modules isn't ideal, since it > > > is largely "aspirational" unless it is coupled with a KERNEL_FEATURE > > > that is set based on a machine or distro feature. > > > > I have to admit that I feel a bit lost. I am not really sure I > > understood what you meant. > > > > Is the "generic bucket" cfg/sound.scc? But why should we break that > > up? A module only ends up in an image if the module is installed. And > > the installation is controlled e.g. by MACHINE_EXTRA_RRECOMMENDS in > > the machine file. > > I might also be misunderstanding but I think what Bruce is asking is > that the qemux86 sound pieces be broken out of cfg/sound.scc. In case > you didn't find them, the files are here: > > https://git.yoctoproject.org/yocto-kernel-cache/tree/cfg/sound.scc > https://git.yoctoproject.org/yocto-kernel-cache/tree/cfg/sound.cfg > > and the question is which of the options in sound.cfg are the drivers > which qemu needs on x86. > > I think Bruce would like a patch which splits those items out and > triggers them on qemux86 specifically. > > This means if things change in future, we know exactly which module > options we need for sound on qemux86. > > Bruce can correct me if I misunderstand! :) Yes, that makes sense to me. But I have to admit that I neither have the time nor the sound driver knowledge to do this properly. I am afraid that it would not be sufficient to simply break out the driver needed for QEMU ie., intel8x0 and its dependencies. sound.cfg contains support for a lot of different sound cards which share kernel config options / modules. It can be done and the scc files support that but that is too much time needed for me right now. Sorry. What I actually wanted to achieve is to build Doom with YP and run it in QEMU. And even though the correct sound drivers are now loaded I do not get sound using e.g., aplay /usr/share/sounds/alsa/Front_Center.wav. > > > If you search the mailing list archives, you'll see me musing about > > > how I need to change those unconditional appends of option to qemu, as > > > it makes defining a new qemu machine problematic (if the options are > > > causing issues). The tweak I'm describing is a small step in that > > > direction. > > > > What I understood is that you propose to change the existing > > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > in e.g. linux-yocto_5.19.bb to (remove cfg/sound.scc) > > > > KERNEL_FEATURES:append:qemux86=" cfg/paravirt_kvm.scc" > > KERNEL_FEATURES:append:qemux86-64=" cfg/paravirt_kvm.scc" > > > > and add (move) the following into linux-yocto.inc > > > > KERNEL_FEATURES:append:qemuall=" > > ${@bb.utils.contains('MACHINE_FEATURES', 'alsa', 'cfg/sound.scc', '', > > d)}" > > > > That is, instead of coupling the compilation of QEMU sound driver > > modules based on machine name qemux86 and qemux86-64 we activate it > > for all QEMU machines which also have alsa as a MACHINE_FEATURE. And > > that is set in machine/include/qemu.inc. > > > > > One new question comes to mind, what init system were you testing with > > > (default poky and sysvinit ?) ? If we now have the proper init system, > > > are no events being triggered to load the modules now that the proper > > > ones are in the machine files ? > > > > I was testing on Poky with the default init system i.e, sysvinit. > > Without the KERNEL_MODULE_AUTOLOAD line the snd-intel8x0 module is not > > loaded. > > > > And it seems you are right: The KERNEL_MODULE_AUTOLOAD is superfluous. > > Even when I remove the second patch the modules are still loaded. I am > > a little puzzled why it originally seemed to me that it was necessary. > > I'm not sure on that. The kernel will try and autoprobe for drivers for > hardware it has present where it can though. I'll wait for Bruce's feedback and then send an updated patch which fixes the QEMU machine file. Cheers, Mark
On Fri, Jan 6, 2023 at 5:13 AM Mark Jonas <toertel@gmail.com> wrote: > > Hi Bruce, > > On Thu, Jan 5, 2023 at 3:57 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > On Thu, Jan 5, 2023 at 8:42 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > Hi Bruce, > > > > > > On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > > > > > From: Mark Jonas <toertel@gmail.com> > > > > > > > > > > If DISTRO_FEATURES includes ALSA then automatically load the > > > > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the > > > > > machine configurations conf/machine/qemux86.conf and qemux86-64.conf. > > > > > > > > > > Signed-off-by: Mark Jonas <toertel@gmail.com> > > > > > --- > > > > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++ > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > index 091003ed82..c8a9b0a1e3 100644 > > > > > --- a/meta/recipes-kernel/linux/linux-yocto.inc > > > > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" > > > > > > > > > > +# sound driver recommended by conf/machine/qemux86*.conf > > > > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" > > > > > > > > This gets us most of the way, but if we are going to do this we should > > > > complete the job. > > > > > > > > We really need to make sure there's a configuration fragment that > > > > explicitly enables > > > > the modules we need (and not count on defaults, or other selects). That would go > > > > into the kernel-cache. > > > > > > > > It would then be something we'd add to the KERNEL_FEATRES triggered off the > > > > distro feature. Just like we are doing with numa and vfat that is visible in the > > > > context of the patch. > > > > > > In my understanding this is already the case. See for example > > > linux-yocto_5.19.bb which contains the following lines. > > > > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > > > Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD > > > into the same file where the corresponding configuration fragment is > > > added? But that would mean to duplicate the lines over five recipes. > > > > > > Alternatively I could move the cfg/sound.scc out of the recipes into > > > the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also > > > get it. > > > > I definitely wasn't clear. Sorry about that, I'm still partially on > > holidays and didn't have enough coffee when I wrote that. > > > > That is close to what I meant. It is one thing to define the options > > in our generic sound "buckets" and another to put a specific module > > into the autoload. > > > > If we are going to autoload a module, the option really should be > > pulled out of the generic bucket, and put into something smaller / > > specific to what we are trying to do, and trigger the inclusion of > > that fragment only when the appropriate distro feature is set. The > > machine conf files specifying specific modules isn't ideal, since it > > is largely "aspirational" unless it is coupled with a KERNEL_FEATURE > > that is set based on a machine or distro feature. > > I have to admit that I feel a bit lost. I am not really sure I > understood what you meant. I'll reply here, and then to the follow up email. I've read them all and will clarify. > > Is the "generic bucket" cfg/sound.scc? But why should we break that > up? A module only ends up in an image if the module is installed. And > the installation is controlled e.g. by MACHINE_EXTRA_RRECOMMENDS in > the machine file. Having really broad configuration buckets that build a lot of "just in case" drivers, aren't a great idea. We've been making things more feature based and refined over the past decade or so. The "kernel-modules" package will install them all. Just because in this case we are using the individual module packages, doesn't mean that is always the case. Spreading very specific module package names into machine configuration files is also problematic, as the modules come and go, change names, etc. I'm always juggling a few each kernel upgrade. Keeping that knowledge centralized, makes things easier .. as witnessed by the need to tweak the sound modules in this thread. > > > If you search the mailing list archives, you'll see me musing about > > how I need to change those unconditional appends of option to qemu, as > > it makes defining a new qemu machine problematic (if the options are > > causing issues). The tweak I'm describing is a small step in that > > direction. > > What I understood is that you propose to change the existing > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > in e.g. linux-yocto_5.19.bb to (remove cfg/sound.scc) > > KERNEL_FEATURES:append:qemux86=" cfg/paravirt_kvm.scc" > KERNEL_FEATURES:append:qemux86-64=" cfg/paravirt_kvm.scc" > > and add (move) the following into linux-yocto.inc > > KERNEL_FEATURES:append:qemuall=" > ${@bb.utils.contains('MACHINE_FEATURES', 'alsa', 'cfg/sound.scc', '', > d)}" > > That is, instead of coupling the compilation of QEMU sound driver > modules based on machine name qemux86 and qemux86-64 we activate it > for all QEMU machines which also have alsa as a MACHINE_FEATURE. And > that is set in machine/include/qemu.inc. I'll follow up to this in a reply to Richard's clarification. > > > One new question comes to mind, what init system were you testing with > > (default poky and sysvinit ?) ? If we now have the proper init system, > > are no events being triggered to load the modules now that the proper > > ones are in the machine files ? > > I was testing on Poky with the default init system i.e, sysvinit. > Without the KERNEL_MODULE_AUTOLOAD line the snd-intel8x0 module is not > loaded. > > And it seems you are right: The KERNEL_MODULE_AUTOLOAD is superfluous. > Even when I remove the second patch the modules are still loaded. I am > a little puzzled why it originally seemed to me that it was necessary. The autoloading is the behaviour that I expected, but I can't explain why it wasn't working in your earlier tests! Bruce > > Cheers, > Mark
On Fri, Jan 6, 2023 at 6:27 AM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Fri, 2023-01-06 at 11:13 +0100, Mark Jonas wrote: > > Hi Bruce, > > > > On Thu, Jan 5, 2023 at 3:57 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > On Thu, Jan 5, 2023 at 8:42 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > > > Hi Bruce, > > > > > > > > On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > > > > > > > From: Mark Jonas <toertel@gmail.com> > > > > > > > > > > > > If DISTRO_FEATURES includes ALSA then automatically load the > > > > > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the > > > > > > machine configurations conf/machine/qemux86.conf and qemux86-64.conf. > > > > > > > > > > > > Signed-off-by: Mark Jonas <toertel@gmail.com> > > > > > > --- > > > > > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++ > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > > index 091003ed82..c8a9b0a1e3 100644 > > > > > > --- a/meta/recipes-kernel/linux/linux-yocto.inc > > > > > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ > > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" > > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" > > > > > > > > > > > > +# sound driver recommended by conf/machine/qemux86*.conf > > > > > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" > > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" > > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" > > > > > > > > > > This gets us most of the way, but if we are going to do this we should > > > > > complete the job. > > > > > > > > > > We really need to make sure there's a configuration fragment that > > > > > explicitly enables > > > > > the modules we need (and not count on defaults, or other selects). That would go > > > > > into the kernel-cache. > > > > > > > > > > It would then be something we'd add to the KERNEL_FEATRES triggered off the > > > > > distro feature. Just like we are doing with numa and vfat that is visible in the > > > > > context of the patch. > > > > > > > > In my understanding this is already the case. See for example > > > > linux-yocto_5.19.bb which contains the following lines. > > > > > > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > > > > > Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD > > > > into the same file where the corresponding configuration fragment is > > > > added? But that would mean to duplicate the lines over five recipes. > > > > > > > > Alternatively I could move the cfg/sound.scc out of the recipes into > > > > the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also > > > > get it. > > > > > > I definitely wasn't clear. Sorry about that, I'm still partially on > > > holidays and didn't have enough coffee when I wrote that. > > > > > > That is close to what I meant. It is one thing to define the options > > > in our generic sound "buckets" and another to put a specific module > > > into the autoload. > > > > > > If we are going to autoload a module, the option really should be > > > pulled out of the generic bucket, and put into something smaller / > > > specific to what we are trying to do, and trigger the inclusion of > > > that fragment only when the appropriate distro feature is set. The > > > machine conf files specifying specific modules isn't ideal, since it > > > is largely "aspirational" unless it is coupled with a KERNEL_FEATURE > > > that is set based on a machine or distro feature. > > > > I have to admit that I feel a bit lost. I am not really sure I > > understood what you meant. > > > > Is the "generic bucket" cfg/sound.scc? But why should we break that > > up? A module only ends up in an image if the module is installed. And > > the installation is controlled e.g. by MACHINE_EXTRA_RRECOMMENDS in > > the machine file. > > I might also be misunderstanding but I think what Bruce is asking is > that the qemux86 sound pieces be broken out of cfg/sound.scc. In case > you didn't find them, the files are here: > > https://git.yoctoproject.org/yocto-kernel-cache/tree/cfg/sound.scc > https://git.yoctoproject.org/yocto-kernel-cache/tree/cfg/sound.cfg > > and the question is which of the options in sound.cfg are the drivers > which qemu needs on x86. > > I think Bruce would like a patch which splits those items out and > triggers them on qemux86 specifically. > > This means if things change in future, we know exactly which module > options we need for sound on qemux86. > > Bruce can correct me if I misunderstand! :) That is correct! Something like sonud-intel.scc/cfg or sound-qemu.scc/cfg that just contains what we need for those particular drivers, as they have a well defined use case, and there's no need for ALL the other drivers to be enabled, built and packaged if you really know your target machine. The KERNEL_FEATURES append would then be something like: SOUND_FEATURES="${@bb.utils.contains('MACHINE_FEATURES', 'alsa', 'cfg/sound-intel.scc', '', d)}" KERNEL_FEATURES:append:qemux86=" ${SOUND_FEATURES} cfg/paravirt_kvm.scc" Or it could all be done in the single append, etc, but having it in a variable might give us more flexibility for other qemu or target machines to re-use it. My example keeps the machine specific enablement in the KERNEL_FEATURES append, but there are any number of ways to do it (since my proposed configuration fragment has "intel" in it, it could be confusing :)) Bruce > > > > If you search the mailing list archives, you'll see me musing about > > > how I need to change those unconditional appends of option to qemu, as > > > it makes defining a new qemu machine problematic (if the options are > > > causing issues). The tweak I'm describing is a small step in that > > > direction. > > > > What I understood is that you propose to change the existing > > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > in e.g. linux-yocto_5.19.bb to (remove cfg/sound.scc) > > > > KERNEL_FEATURES:append:qemux86=" cfg/paravirt_kvm.scc" > > KERNEL_FEATURES:append:qemux86-64=" cfg/paravirt_kvm.scc" > > > > and add (move) the following into linux-yocto.inc > > > > KERNEL_FEATURES:append:qemuall=" > > ${@bb.utils.contains('MACHINE_FEATURES', 'alsa', 'cfg/sound.scc', '', > > d)}" > > > > That is, instead of coupling the compilation of QEMU sound driver > > modules based on machine name qemux86 and qemux86-64 we activate it > > for all QEMU machines which also have alsa as a MACHINE_FEATURE. And > > that is set in machine/include/qemu.inc. > > > > > One new question comes to mind, what init system were you testing with > > > (default poky and sysvinit ?) ? If we now have the proper init system, > > > are no events being triggered to load the modules now that the proper > > > ones are in the machine files ? > > > > I was testing on Poky with the default init system i.e, sysvinit. > > Without the KERNEL_MODULE_AUTOLOAD line the snd-intel8x0 module is not > > loaded. > > > > And it seems you are right: The KERNEL_MODULE_AUTOLOAD is superfluous. > > Even when I remove the second patch the modules are still loaded. I am > > a little puzzled why it originally seemed to me that it was necessary. > > I'm not sure on that. The kernel will try and autoprobe for drivers for > hardware it has present where it can though. > > Cheers, > > Richard > >
On Fri, Jan 6, 2023 at 10:06 AM Mark Jonas <toertel@gmail.com> wrote: > > Hi Richard and Bruce, > > On Fri, Jan 6, 2023 at 12:27 PM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Fri, 2023-01-06 at 11:13 +0100, Mark Jonas wrote: > > > Hi Bruce, > > > > > > On Thu, Jan 5, 2023 at 3:57 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > On Thu, Jan 5, 2023 at 8:42 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > > > > > Hi Bruce, > > > > > > > > > > On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > > > > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas <toertel@gmail.com> wrote: > > > > > > > > > > > > > > From: Mark Jonas <toertel@gmail.com> > > > > > > > > > > > > > > If DISTRO_FEATURES includes ALSA then automatically load the > > > > > > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the > > > > > > > machine configurations conf/machine/qemux86.conf and qemux86-64.conf. > > > > > > > > > > > > > > Signed-off-by: Mark Jonas <toertel@gmail.com> > > > > > > > --- > > > > > > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++ > > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > > > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > > > index 091003ed82..c8a9b0a1e3 100644 > > > > > > > --- a/meta/recipes-kernel/linux/linux-yocto.inc > > > > > > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc > > > > > > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ > > > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" > > > > > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" > > > > > > > > > > > > > > +# sound driver recommended by conf/machine/qemux86*.conf > > > > > > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" > > > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" > > > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" > > > > > > > > > > > > This gets us most of the way, but if we are going to do this we should > > > > > > complete the job. > > > > > > > > > > > > We really need to make sure there's a configuration fragment that > > > > > > explicitly enables > > > > > > the modules we need (and not count on defaults, or other selects). That would go > > > > > > into the kernel-cache. > > > > > > > > > > > > It would then be something we'd add to the KERNEL_FEATRES triggered off the > > > > > > distro feature. Just like we are doing with numa and vfat that is visible in the > > > > > > context of the patch. > > > > > > > > > > In my understanding this is already the case. See for example > > > > > linux-yocto_5.19.bb which contains the following lines. > > > > > > > > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > > > > > > > Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD > > > > > into the same file where the corresponding configuration fragment is > > > > > added? But that would mean to duplicate the lines over five recipes. > > > > > > > > > > Alternatively I could move the cfg/sound.scc out of the recipes into > > > > > the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also > > > > > get it. > > > > > > > > I definitely wasn't clear. Sorry about that, I'm still partially on > > > > holidays and didn't have enough coffee when I wrote that. > > > > > > > > That is close to what I meant. It is one thing to define the options > > > > in our generic sound "buckets" and another to put a specific module > > > > into the autoload. > > > > > > > > If we are going to autoload a module, the option really should be > > > > pulled out of the generic bucket, and put into something smaller / > > > > specific to what we are trying to do, and trigger the inclusion of > > > > that fragment only when the appropriate distro feature is set. The > > > > machine conf files specifying specific modules isn't ideal, since it > > > > is largely "aspirational" unless it is coupled with a KERNEL_FEATURE > > > > that is set based on a machine or distro feature. > > > > > > I have to admit that I feel a bit lost. I am not really sure I > > > understood what you meant. > > > > > > Is the "generic bucket" cfg/sound.scc? But why should we break that > > > up? A module only ends up in an image if the module is installed. And > > > the installation is controlled e.g. by MACHINE_EXTRA_RRECOMMENDS in > > > the machine file. > > > > I might also be misunderstanding but I think what Bruce is asking is > > that the qemux86 sound pieces be broken out of cfg/sound.scc. In case > > you didn't find them, the files are here: > > > > https://git.yoctoproject.org/yocto-kernel-cache/tree/cfg/sound.scc > > https://git.yoctoproject.org/yocto-kernel-cache/tree/cfg/sound.cfg > > > > and the question is which of the options in sound.cfg are the drivers > > which qemu needs on x86. > > > > I think Bruce would like a patch which splits those items out and > > triggers them on qemux86 specifically. > > > > This means if things change in future, we know exactly which module > > options we need for sound on qemux86. > > > > Bruce can correct me if I misunderstand! :) > > Yes, that makes sense to me. But I have to admit that I neither have > the time nor the sound driver knowledge to do this properly. I am > afraid that it would not be sufficient to simply break out the driver > needed for QEMU ie., intel8x0 and its dependencies. sound.cfg contains > support for a lot of different sound cards which share kernel config > options / modules. It can be done and the scc files support that but > that is too much time needed for me right now. Sorry. I can help with this part, since I don't want to lose the contribution by asking for too much! It really is just putting the =m configuration for the modules into a separate config, with any direct dependencies in that same file. If you send a patch that does the tweaking of the enablement, I can pull it into my queue and split out the fragments to something specific to what we need, and submit them all as a series. Bruce > > What I actually wanted to achieve is to build Doom with YP and run it > in QEMU. And even though the correct sound drivers are now loaded I do > not get sound using e.g., aplay > /usr/share/sounds/alsa/Front_Center.wav. > > > > > If you search the mailing list archives, you'll see me musing about > > > > how I need to change those unconditional appends of option to qemu, as > > > > it makes defining a new qemu machine problematic (if the options are > > > > causing issues). The tweak I'm describing is a small step in that > > > > direction. > > > > > > What I understood is that you propose to change the existing > > > > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" > > > > > > in e.g. linux-yocto_5.19.bb to (remove cfg/sound.scc) > > > > > > KERNEL_FEATURES:append:qemux86=" cfg/paravirt_kvm.scc" > > > KERNEL_FEATURES:append:qemux86-64=" cfg/paravirt_kvm.scc" > > > > > > and add (move) the following into linux-yocto.inc > > > > > > KERNEL_FEATURES:append:qemuall=" > > > ${@bb.utils.contains('MACHINE_FEATURES', 'alsa', 'cfg/sound.scc', '', > > > d)}" > > > > > > That is, instead of coupling the compilation of QEMU sound driver > > > modules based on machine name qemux86 and qemux86-64 we activate it > > > for all QEMU machines which also have alsa as a MACHINE_FEATURE. And > > > that is set in machine/include/qemu.inc. > > > > > > > One new question comes to mind, what init system were you testing with > > > > (default poky and sysvinit ?) ? If we now have the proper init system, > > > > are no events being triggered to load the modules now that the proper > > > > ones are in the machine files ? > > > > > > I was testing on Poky with the default init system i.e, sysvinit. > > > Without the KERNEL_MODULE_AUTOLOAD line the snd-intel8x0 module is not > > > loaded. > > > > > > And it seems you are right: The KERNEL_MODULE_AUTOLOAD is superfluous. > > > Even when I remove the second patch the modules are still loaded. I am > > > a little puzzled why it originally seemed to me that it was necessary. > > > > I'm not sure on that. The kernel will try and autoprobe for drivers for > > hardware it has present where it can though. > > I'll wait for Bruce's feedback and then send an updated patch which > fixes the QEMU machine file. > > Cheers, > Mark
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc index 091003ed82..c8a9b0a1e3 100644 --- a/meta/recipes-kernel/linux/linux-yocto.inc +++ b/meta/recipes-kernel/linux/linux-yocto.inc @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/ KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 'features/numa/numa.scc', '', d)}" KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc', '', d)}" +# sound driver recommended by conf/machine/qemux86*.conf +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "snd-intel8x0", "", d)}" +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}" +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}" + # A KMACHINE is the mapping of a yocto $MACHINE to what is built # by the kernel. This is typically the branch that should be built, # and it can be specific to the machine or shared