| Message ID | 20240227170902.3718203-2-ejo@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
| Series | [1/3] kernel.bbclass: slightly fix wording, case, and spaces in version check | expand |
On Tue, Feb 27, 2024 at 12:09 PM Enrico Jörns <ejo@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 :) Bruce > > Signed-off-by: Enrico Jörns <ejo@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 >
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 <ejo@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..? Regards, Enrico > Bruce > > > > > Signed-off-by: Enrico Jörns <ejo@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 > > > >
On Tue, Feb 27, 2024 at 1:55 PM Enrico Jörns <ejo@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 <ejo@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. Bruce > > Regards, Enrico > > > Bruce > > > > > > > > Signed-off-by: Enrico Jörns <ejo@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 |
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 <ejo@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 <ejo@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 <ejo@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 | > > >
On Tue, Feb 27, 2024 at 2:32 PM Enrico Jörns <ejo@pengutronix.de> wrote: > > 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 <ejo@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 <ejo@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.) I do have a very strong opinion. If we were going to do that, I also would have done it many years ago. Having some, but not all of the meta-data and merging split between the classes would be a disaster. If there's something that the meta-data handling is doing in kernel-yocto bbclass that isn't working or isn't appropriate, we can fix it there. Other layers and classes in those layers are of course free to do whatever they want, but we need to be consistent in core. In fact, I've had a bug and a prototype patch for many years now that does move some of the configuration merging to kernel.bbclass, but it only increases complexity and doesn't offer any benefits .. again, since if there's something wrong with the fragment gathering and merging in the kernel-yocto bbclass that makes it not broadly applicable, we need to fix it there, not make things more complex and confusing by arbitrarily splitting it into something unmaintainable. Bruce > > > Enrico > > > Bruce > > > > > > > > Regards, Enrico > > > > > > > Bruce > > > > > > > > > > > > > > Signed-off-by: Enrico Jörns <ejo@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 |
Am Dienstag, dem 27.02.2024 um 14:46 -0500 schrieb Bruce Ashfield: > On Tue, Feb 27, 2024 at 2:32 PM Enrico Jörns <ejo@pengutronix.de> wrote: > > > > 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 <ejo@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 <ejo@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.) > > I do have a very strong opinion. > > If we were going to do that, I also would have done it many years ago. > > Having some, but not all of the meta-data and merging split between the > classes would be a disaster. I would not call config fragments 'meta-data' and was thinking more about something that is replaced by kernel-yocto.bbclass. That a split of meta-data handling would be a disaster is something I would agree on. > If there's something that the meta-data handling is doing in kernel-yocto > bbclass that isn't working or isn't appropriate, we can fix it there. Ok, if the opinion is that strong, than this is the way to go for me first of all. (However, I do not have any meta-data in mind in our use case anyway.) > Other layers and classes in those layers are of course free to do whatever > they want, but we need to be consistent in core. Clear. > In fact, I've had a bug and a prototype patch for many years now that > does move some of the configuration merging to kernel.bbclass, but it > only increases complexity and doesn't offer any benefits .. again, since > if there's something wrong with the fragment gathering and merging > in the kernel-yocto bbclass that makes it not broadly applicable, we need > to fix it there, not make things more complex and confusing by arbitrarily > splitting it into something unmaintainable. Keeping it maintainable should be the primary goal, indeed! I would not call it 'arbitrarily splitting' but at a well-defined point (*no* meta-data vs. meta- data), but if you have already tried to do a proper split I'd keep this as a good hint first of all that the topic is quite tricky. Thanks for sharing your opinions on that
On Tue, Feb 27, 2024 at 4:01 PM Enrico Jörns <ejo@pengutronix.de> wrote: > > Am Dienstag, dem 27.02.2024 um 14:46 -0500 schrieb Bruce Ashfield: > > On Tue, Feb 27, 2024 at 2:32 PM Enrico Jörns <ejo@pengutronix.de> wrote: > > > > > > 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 <ejo@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 <ejo@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.) > > > > I do have a very strong opinion. > > > > If we were going to do that, I also would have done it many years ago. > > > > Having some, but not all of the meta-data and merging split between the > > classes would be a disaster. > > I would not call config fragments 'meta-data' and was thinking more about something that is replaced > by kernel-yocto.bbclass. That a split of meta-data handling would be a disaster is something I would > agree on. That is what we've always called them, because it isn't just the fragments that are the important part, it is the common nature of the fragments (the actual merge_config upstreamining is something that grew out of what we have, and I participated in the effort). The fragments abstract and describe the feature and carry information about how they should be applied (and in theory, are used along with the patches), hence the "meta" information they carry. By keeping the official support in kernel-yocto, and leveraging the kernel-cache as the common location for the fragments, we've been gathering / consolidating for 10 years now. If fragments end up sprayed everywhere (which they still can, even with the kernel-yocto centre of mass), then really we haven't done much else besides whacking some text files into a larger text file. > > > If there's something that the meta-data handling is doing in kernel-yocto > > bbclass that isn't working or isn't appropriate, we can fix it there. > > Ok, if the opinion is that strong, than this is the way to go for me first of all. > (However, I do not have any meta-data in mind in our use case anyway.) > > > Other layers and classes in those layers are of course free to do whatever > > they want, but we need to be consistent in core. > > Clear. > > > In fact, I've had a bug and a prototype patch for many years now that > > does move some of the configuration merging to kernel.bbclass, but it > > only increases complexity and doesn't offer any benefits .. again, since > > if there's something wrong with the fragment gathering and merging > > in the kernel-yocto bbclass that makes it not broadly applicable, we need > > to fix it there, not make things more complex and confusing by arbitrarily > > splitting it into something unmaintainable. > > Keeping it maintainable should be the primary goal, indeed! > I would not call it 'arbitrarily splitting' but at a well-defined point (*no* meta-data vs. meta- > data), but if you have already tried to do a proper split I'd keep this as a good hint first of all > that the topic is quite tricky. If the merging happens in one place, the fragments coming from another and the audit of the results living in a 3rd, then we are definitely splitting things and making it more complex than it already is. If there really is something causing issues in the kernel-yocto implementation, then that's where I'm interested in seeing what the issues are, and how we can fix it. Bruce > > Thanks for sharing your opinions on that
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
The kernel patches may modify the kernel version, thus wait for do_patch before running the version check. Signed-off-by: Enrico Jörns <ejo@pengutronix.de> --- meta/classes-recipe/kernel-yocto.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)