Am Dienstag, dem 27.02.2024 um 14:13 -0500 schrieb Bruce Ashfield:
> On Tue, Feb 27, 2024 at 1:55 PM Enrico Jörns <e...@pengutronix.de> wrote:
> >
> > Am Dienstag, dem 27.02.2024 um 12:36 -0500 schrieb Bruce Ashfield:
> > > On Tue, Feb 27, 2024 at 12:09 PM Enrico Jörns <e...@pengutronix.de> wrote:
> > > >
> > > > The kernel patches may modify the kernel version, thus wait for do_patch
> > > > before running the version check.
> > >
> > > While that may be true for kernel's in general, I sincerely hope that no
> > > one is
> > > patching in a new kernel version to linux-yocto.
> > >
> > > I don't have any great concerns with the patch, I just don't think it
> > > is necessary :)
> >
> > Yes, the use case is actually not linux-yocto itself.
> > Thus it might be most relevant in combination with moving the version check
> > to kernel.bbclass.
> >
> > How I actually came across this check is that (in some projects) we use the
> > linux-yocto.bbclass
> > for
> > non-linux-yocto kernels since some functionality (especially fragment
> > handling) seems useful in
> > general.
> >
> > I am still unsure if I should try to move (or duplicate) the required
> > features in the generic
> > kernel.bbclass or if using linux-yocto.bbclass for 'mainline' kernel is an
> > appropriate use
> > case..?
> >
>
> There's no need to use the linux-yocto repository when using
> kernel-yocto bbclass, so
> definitely, it is an acceptable use case. In fact meta-mainline, and
> linux-yocto themselves
> are both using kernel-yocto bbclass to build mainline/-stable kernels.
>
> I'd rather not move the kernel-yocto bits into kernel.bbclass, since
> if that was something
> easily done .. I would have done it a long time ago.
>
> Keeping the split in the functionality allows those that don't care
> about linux-yocto to
> keep their recipes and workflow the same, and those that want to opt
> into the kernel-yocto
> functionality can just inherit the class.
Yes, I wouldn't move the meta data handling and its tricky pieces, since this
is actually something
I see in kernel-yocto.bbclass, too.
But.. do you have an opinion on adding simple config fragment handling in
kernel.bbclass (like we
have in busybox or u-boot)? So mainly calling merge_config.sh somewhere around
do_configure.
(It would however need to be compatible with (or replaced by) the more advanced
handling in kernel-
yocto.bbclass.)
Enrico
> Bruce
>
> >
> > Regards, Enrico
> >
> > > Bruce
> > >
> > > >
> > > > Signed-off-by: Enrico Jörns <e...@pengutronix.de>
> > > > ---
> > > > meta/classes-recipe/kernel-yocto.bbclass | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/classes-recipe/kernel-yocto.bbclass
> > > > b/meta/classes-recipe/kernel-
> > > > yocto.bbclass
> > > > index 108b7e6752..854e4681d5 100644
> > > > --- a/meta/classes-recipe/kernel-yocto.bbclass
> > > > +++ b/meta/classes-recipe/kernel-yocto.bbclass
> > > > @@ -729,6 +729,6 @@ python () {
> > > > }
> > > >
> > > > # extra tasks
> > > > -addtask kernel_version_sanity_check after do_kernel_metadata
> > > > do_kernel_checkout before
> > > > do_compile
> > > > +addtask kernel_version_sanity_check after do_patch before do_compile
> > > > addtask validate_branches before do_patch after do_kernel_checkout
> > > > addtask kernel_configcheck after do_configure before do_compile
> > > > --
> > > > 2.39.2
> > > >
> > >
> > >
> >
> > --
> > Pengutronix e.K. | Enrico Jörns |
> > Embedded Linux Consulting & Support | https://www.pengutronix.de/ |
> > Steuerwalder Str. 21 | Phone: +49-5121-206917-180 |
> > 31137 Hildesheim, Germany | Fax: +49-5121-206917-9 |
>
>
>
--
Pengutronix e.K. | Enrico Jörns |
Embedded Linux Consulting & Support | https://www.pengutronix.de/ |
Steuerwalder Str. 21 | Phone: +49-5121-206917-180 |
31137 Hildesheim, Germany | Fax: +49-5121-206917-9 |
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196293):
https://lists.openembedded.org/g/openembedded-core/message/196293
Mute This Topic: https://lists.openembedded.org/mt/104606847/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
