Kernel recipes with broken PRs now

Kernel recipes with broken PRs now

[Tom Rini]

Hey all.  With the MACHINE_KERNEL_PR stuff, the following recipes will
now revert to r0 rather than:
openembedded/recipes/linux$ grep -E "^PR[[:blank:]]+=" *.inc *.bb
gumstix-linux.inc:PR = "r1"
openzaurus-pxa_2.4.18-rmk7-pxa3-embedix20031107.inc:PR = "r46"
c7x0-kernels-2.4-embedix.bb:PR = "r1"
chumby-kernel_2.6.16-chumby-1.2.bb:PR = "r4"
collie-kernels-2.4-embedix.bb:PR = "r2"
compulab-pxa270_2.6.16.bb:PR = "r6"
devkitidp-pxa255_2.6.19.bb:PR = "r4"
em-x270_2.6.23.bb:PR = "r1"
ep93xx-kernel_2.6.17+2.6.18-rc1.bb:PR = "r1"
ep93xx-kernel_2.6.19+2.6.20-rc7.bb:PR = "r1"
fsg3-kernel_2.6.18.bb:PR = "r1.${IXP4XX_KERNEL_SVN_REV}"
ixp4xx-kernel_2.6.18.bb:PR = "r1.${IXP4XX_KERNEL_SVN_REV}"
ixp4xx-kernel_2.6.19.bb:PR = "r1.${IXP4XX_KERNEL_SVN_REV}"
ixp4xx-kernel_2.6.20.bb:PR = "r4.${IXP4XX_KERNEL_SVN_REV}"
ixp4xx-kernel_2.6.21.6.bb:PR = "r2.${IXP4XX_KERNEL_SVN_REV}"
ixp4xx-kernel_2.6.23.8.bb:PR = "r0.${IXP4XX_KERNEL_SVN_REV}"
linux_2.6.20.bb:PR = "r8"
linux_2.6.21+2.6.22-rc1.bb:PR = "r2"
linux_2.6.21.bb:PR = "r12"
linux_2.6.22+2.6.23-rc3.bb:PR = "r1"
linux_2.6.22+2.6.23-rc5.bb:PR = "r1"
linux_2.6.22.6.bb:PR = "r1"
linux_2.6.22.bb:PR = "r5"
linux_2.6.23+2.6.24-rc5.bb:PR = "r3"
linux_2.6.23.bb:PR = "r12"
linux_2.6.24.bb:PR = "r31"
linux_2.6.25.20.bb:PR = "r2"
linux_2.6.25.bb:PR = "r6"
linux_2.6.26.bb:PR = "r9"
linux_2.6.27.bb:PR = "r8"
linux_2.6.28.bb:PR = "r8"
linux_2.6.28-rc6.bb:PR = "r3"
linux_2.6.29+2.6.30-rc4.bb:PR = "r1"
linux_2.6.29+2.6.30-rc5.bb:PR = "r1"
linux_2.6.29.bb:PR = "r4"
linux-bd-neon-2.6_2.6.22.bb:PR = "r2"
linux-bug_2.6.27.2.bb:PR = "r27"
linux-davinci_2.6.25.bb:PR = "r3"
linux-davinci_git.bb:PR = "r4"
linux-dht-walnut_2.6.20.bb:PR = "r4"
linux-efika_2.6.18+2.6.19-rc6.bb:PR = "r3"
linux-efika_2.6.20.20.bb:PR = "r2"
linux-efika_2.6.20.bb:PR = "r2"
linux-epia_2.6.19.2.bb:PR = "r1"
linux-epia_2.6.8.1.bb:PR = "r15"
linux-eten_2.6.28-rc4+git.bb:PR = "r2"
linux-gumstix_2.6.15.bb:PR = "r2"
linux-h1940_2.6.17-h1940.bb:PR = "r1"
linux-hackndev-2.6_git.bb:PR = "r14"
linux-handhelds-2.6_2.6.17-hh4.bb:PR = "r1"
linux-handhelds-2.6_2.6.19-hh13.bb:PR = "r1"
linux-handhelds-2.6_2.6.20-hh10.bb:PR = "r1"
linux-handhelds-2.6_2.6.21-hh20.bb:PR = "r25"
linux-ixp4xx_2.6.24.7.bb:PR = "r1"
linux-ixp4xx_2.6.27.8.bb:PR = "r2"
linux-jlime-current.bb:PR = "r1"
linux-magicbox_2.6.18.6.bb:PR = "r2"
linux-magicbox_2.6.19.2.bb:PR = "r3"
linux-ml403-mvista-2.6.x_git.bb:PR = "r1"
linux-msm7xxxx_git.bb:PR = "r13"
linux-mtx-1_2.4.27.bb:PR = "r11"
linux-mtx-1u_2.4.27.bb:PR = "r11"
linux-mtx-2_2.4.27.bb:PR = "r11"
linux-mtx-3_2.6.15.4.bb:PR = "r11"
linux-mtx-3_2.6.15.bb:PR = "r11"
linux-n1200_2.6.27-rc9+git.bb:PR = "r3"
linux-neuros_2.6.15.bb:PR = "r5"
linux-neuros_git.bb:PR = "r14"
linux-nokia800_2.6.18-osso40.bb:PR = "r5"
linux-nokia800_2.6.21-osso71.bb:PR = "r5"
linux-omap1_2.6.12-rc2.bb:PR = "r4"
linux-omap1_2.6.18+git.bb:PR = "r2"
linux-omap_2.6.26.bb:PR = "r65"
linux-omap_2.6.27.bb:PR = "r14"
linux-omap2_git.bb:PR = "r64"
linux-omap-pm_2.6.28.bb:PR = "r7"
linux-openmoko-2.6.24_git.bb:PR = "r1"
linux-openmoko-devel_git.bb:PR = "r1"
linux-palm-omap1_2.6.22-omap1.bb:PR = "r2"
linux-rp_2.6.23.bb:PR = "r35"
linux-rp_2.6.24.bb:PR = "r22"
linux-rp_2.6.25+2.6.26-rc4.bb:PR = "r6"
linux-rp_2.6.26.bb:PR = "r11"
linux-rt_2.6.24.bb:PR = "r9"
linux-rt_2.6.25.bb:PR = "r4"
linux-smdk2440_2.6.20+git.bb:PR = "r1"
linux-smdk2443_2.6.20+git.bb:PR = "r1"
linux-storcenter_2.6.27.7.bb:PR = "r2"
linux-sun4cdm_2.6.8.1.bb:PR = "r1"
linux-tornado-omap2_2.6.16.16.bb:PR = "r1"
linux-turbostation_2.6.20.2.bb:PR = "r2"
linux-wrt_2.4.20.bb:PR = "r1"
linux-wrt_2.4.30.bb:PR = "r2"
linux-x86_2.6.17.9.bb:PR = "r2"
linux-x86_2.6.20.bb:PR = "r5"
linux-xilinx-slab_git.bb:PR = "r3"
logicpd-pxa270_2.6.17-rc5.bb:PR = "r3"
logicpd-pxa270_2.6.19.2.bb:PR = "r1"
mainstone-kernel_2.6.11.bb:PR = "r1"
mainstone-kernel_2.6.18.bb:PR = "r2"
mnci-ramses_2.4.21-rmk2-pxa1.bb:PR = "r5"
mx21ads-kernel_2.6.19rc6.bb:PR = "r2"
mx31ads-kernel_2.6.19rc6.bb:PR = "r3"
netbook-pro-kernel_2.6.17.bb:PR = "r2"
openezx-kernel_git.bb:PR = "r3"
opensimpad_2.4.25-vrs2-pxa1-jpm1.bb:PR = "r22"
opensimpad_2.4.27-vrs1-pxa1-jpm1.bb:PR = "r4"
openzaurus-pxa27x_2.4.20-rmk2-embedix20050602.bb:PR = "r18"
openzaurus-sa_2.4.18-rmk7-pxa3-embedix20030509.bb:PR = "r23"
xanadux-un-2.6_2.6.12.bb:PR ="r2"

In current .dev.

-- 
Tom Rini

Re: Kernel recipes with broken PRs now

[Andrea Adami]

I think the side-effects of the patch are blessing too much...I'd
propose a rethink of the patch as opt-in.

Andrea

Re: Kernel recipes with broken PRs now

[Koen Kooi]

On 23-05-09 00:27, Andrea Adami wrote:
> I think the side-effects of the patch are blessing too much...

That's called 'incentive' :) You are always complaining about 
unmaintained kernel recipes, now you have a way to identify them :)

> I'd propose a rethink of the patch as opt-in.

Due to the way OE is structured, that's sadly impossible.

regards,

Koen

Re: Kernel recipes with broken PRs now

[Tom Rini]

On Sat, May 23, 2009 at 07:22:56AM +0200, Koen Kooi wrote:
> On 23-05-09 00:27, Andrea Adami wrote:
>> I think the side-effects of the patch are blessing too much...
>
> That's called 'incentive' :) You are always complaining about  
> unmaintained kernel recipes, now you have a way to identify them :)
>
>> I'd propose a rethink of the patch as opt-in.
>
> Due to the way OE is structured, that's sadly impossible.

Can we please get a little write-up on the new variable on the wiki, to
point people at when they hit a broken recipe.

-- 
Tom Rini

Re: Kernel recipes with broken PRs now

[Tom Rini]

On Fri, May 22, 2009 at 10:31:43PM -0700, Tom Rini wrote:
> On Sat, May 23, 2009 at 07:22:56AM +0200, Koen Kooi wrote:
> > On 23-05-09 00:27, Andrea Adami wrote:
> >> I think the side-effects of the patch are blessing too much...
> >
> > That's called 'incentive' :) You are always complaining about  
> > unmaintained kernel recipes, now you have a way to identify them :)
> >
> >> I'd propose a rethink of the patch as opt-in.
> >
> > Due to the way OE is structured, that's sadly impossible.
> 
> Can we please get a little write-up on the new variable on the wiki, to
> point people at when they hit a broken recipe.

Ping.

-- 
Tom Rini

Re: Kernel recipes with broken PRs now

[Koen Kooi]

On 30-05-09 21:13, Tom Rini wrote:
> On Fri, May 22, 2009 at 10:31:43PM -0700, Tom Rini wrote:
>> On Sat, May 23, 2009 at 07:22:56AM +0200, Koen Kooi wrote:
>>> On 23-05-09 00:27, Andrea Adami wrote:
>>>> I think the side-effects of the patch are blessing too much...
>>>
>>> That's called 'incentive' :) You are always complaining about
>>> unmaintained kernel recipes, now you have a way to identify them :)
>>>
>>>> I'd propose a rethink of the patch as opt-in.
>>>
>>> Due to the way OE is structured, that's sadly impossible.
>>
>> Can we please get a little write-up on the new variable on the wiki, to
>> point people at when they hit a broken recipe.
>
> Ping.

You lack write permissions in the wiki? Or do you lack write permissions 
to the usermanual?

regards,

Koen

Re: Kernel recipes with broken PRs now

[Tom Rini]

On Sat, May 30, 2009 at 11:13:34PM +0200, Koen Kooi wrote:
> On 30-05-09 21:13, Tom Rini wrote:
>> On Fri, May 22, 2009 at 10:31:43PM -0700, Tom Rini wrote:
>>> On Sat, May 23, 2009 at 07:22:56AM +0200, Koen Kooi wrote:
>>>> On 23-05-09 00:27, Andrea Adami wrote:
>>>>> I think the side-effects of the patch are blessing too much...
>>>>
>>>> That's called 'incentive' :) You are always complaining about
>>>> unmaintained kernel recipes, now you have a way to identify them :)
>>>>
>>>>> I'd propose a rethink of the patch as opt-in.
>>>>
>>>> Due to the way OE is structured, that's sadly impossible.
>>>
>>> Can we please get a little write-up on the new variable on the wiki, to
>>> point people at when they hit a broken recipe.
>>
>> Ping.
>
> You lack write permissions in the wiki? Or do you lack write permissions  
> to the usermanual?

I lack complete understanding of the When To and a short summary of What
This Does.

-- 
Tom Rini

Re: Kernel recipes with broken PRs now

[Koen Kooi]

On 31-05-09 00:27, Tom Rini wrote:
> On Sat, May 30, 2009 at 11:13:34PM +0200, Koen Kooi wrote:
>> On 30-05-09 21:13, Tom Rini wrote:
>>> On Fri, May 22, 2009 at 10:31:43PM -0700, Tom Rini wrote:
>>>> On Sat, May 23, 2009 at 07:22:56AM +0200, Koen Kooi wrote:
>>>>> On 23-05-09 00:27, Andrea Adami wrote:
>>>>>> I think the side-effects of the patch are blessing too much...
>>>>>
>>>>> That's called 'incentive' :) You are always complaining about
>>>>> unmaintained kernel recipes, now you have a way to identify them :)
>>>>>
>>>>>> I'd propose a rethink of the patch as opt-in.
>>>>>
>>>>> Due to the way OE is structured, that's sadly impossible.
>>>>
>>>> Can we please get a little write-up on the new variable on the wiki, to
>>>> point people at when they hit a broken recipe.
>>>
>>> Ping.
>>
>> You lack write permissions in the wiki? Or do you lack write permissions
>> to the usermanual?
>
> I lack complete understanding of the When To

Always

> and a short summary of What This Does.

This makes external modules and kernel dependant userspace actually work 
if you use a package manager and/or incremental OE builds. Without it 
you rely on sheer luck to keep those working.

regards,

Koen

Re: Kernel recipes with broken PRs now

[Leon Woestenberg]

Hello all,

On Fri, May 22, 2009 at 11:31 PM, Tom Rini <trini@embeddedalley.com> wrote:
> Hey all.  With the MACHINE_KERNEL_PR stuff, the following recipes will

I don't get the use case for MACHINE_KERNEL_PR, can someone explain?

Why would a machine or local.conf want to force rebuild by increasing
this MACHINE_KERNEL_PR variable??

Why does bitbake -c rebuild fail for this use case?


Also, if it makes sense, is this patch handy?

"[oe] [PATCH 1/1] bitbake.conf: make MACHINE_KERNEL_PR defaults to PR'

Regards,
-- 
Leon

Re: Kernel recipes with broken PRs now

[Phil Blundell]

On Sat, 2009-05-23 at 15:06 +0200, Leon Woestenberg wrote:
> I don't get the use case for MACHINE_KERNEL_PR, can someone explain?
> 
> Why would a machine or local.conf want to force rebuild by increasing
> this MACHINE_KERNEL_PR variable??

I think the idea is to rebuild all the module binaries if the kernel
configuration changes in some incompatible way.  However, this does seem
like a curious way of achieving it; I would have thought that the
existing "kernel-abiversion" mechanism, or some extension of that, would
solve the problem without the need to introduce a new user-controlled
global variable.

It does also seem fairly unfortunate that, judging from the first mail
in this thread, the patch in question has been landed in such a way as
to effectively (and silently) rewind PR to r0 for any kernel packages
that haven't been specifically adapted to work with it.

p.

Re: Kernel recipes with broken PRs now

[Leon Woestenberg]

Hello,

On Sat, May 23, 2009 at 6:23 PM, Phil Blundell <philb@gnu.org> wrote:
> On Sat, 2009-05-23 at 15:06 +0200, Leon Woestenberg wrote:
>> Why would a machine or local.conf want to force rebuild by increasing
>> this MACHINE_KERNEL_PR variable??
>
> I think the idea is to rebuild all the module binaries if the kernel
> configuration changes in some incompatible way.  However, this does seem
>
First concern; why would we want to achieve a rebuild on a changed
configuration for the kernel?

We do not support this for other packages, and if we do, we do this in
the regular way by incrementing PR for a new build recipe.

> like a curious way of achieving it; I would have thought that the
> existing "kernel-abiversion" mechanism, or some extension of that, would
> solve the problem without the need to introduce a new user-controlled
> global variable.
>
I found the construction strange to say the least.

My main concern: I think we should simplify OpenEmbedded, not hack it
kaput with strange constructs like these.

> It does also seem fairly unfortunate that, judging from the first mail
> in this thread, the patch in question has been landed in such a way as
> to effectively (and silently) rewind PR to r0 for any kernel packages
> that haven't been specifically adapted to work with it.
>
Marcin wrote a patch that solves this.

However, I wonder where this is going?

Regards,
-- 
Leon

Re: Kernel recipes with broken PRs now

[Koen Kooi]

On 24-05-09 00:25, Leon Woestenberg wrote:

> Marcin wrote a patch that solves this.

Marcins patch doesn't solve anything, it only breaks MACHINE_KERNEL_PR, 
so all your external modules and associated apps don't get rebuilt if 
you change your kernel.

Now, if people posting in this thread would bother to read the original 
RFC (that got approved for .dev as well as stable/2009), we wouldn't be 
having this discussion.

regards,

Koen

Re: Kernel recipes with broken PRs now

[Phil Blundell]

On Sun, 2009-05-24 at 10:23 +0200, Koen Kooi wrote:
> Now, if people posting in this thread would bother to read the original 
> RFC (that got approved for .dev as well as stable/2009), we wouldn't be 
> having this discussion.

I guess the RFC in question is this one:

http://projects.linuxtogo.org/pipermail/openembedded-devel/2009-April/009578.html

but it doesn't seem to really address the issues that have been raised
in this thread.  Indeed, looking at the responses that were posted to
the original RFC it doesn't seem at all obvious that there was a
consensus in favour of the patch; Otavio Salvador said that he was
"fully support[ive]" of it, but everybody else who posted seemed to have
some or other reservations.

If you do want to keep this mechanism then an easy way to make it less
intrusive would be simply to have it be a DISTRO opt-in rather than
standard behaviour.  Then, the distros that want it can be responsible
for making sure that all their kernels have been made compatible with
the patch, and other users don't need to worry about it.  This seems
particularly pertinent for the stable branch where, as I understood it,
intrusive changes were supposed to be avoided.

Per my previous email, though, I think there are probably better ways of
solving the original problem that don't require this kind of global
variable in the first place, and could at least be made to fail in a
"safe" way for users who aren't aware of the change.

p.

Re: Kernel recipes with broken PRs now

[Koen Kooi]

On 24-05-09 11:23, Phil Blundell wrote:
>  This seems
> particularly pertinent for the stable branch where, as I understood it,
> intrusive changes were supposed to be avoided.

Wrong, the stable branch can get intrusive changes as well, the only 
prereq is review and testing, which most changes in .dev never get.

> Per my previous email, though, I think there are probably better ways of
> solving the original problem that don't require this kind of global
> variable in the first place, and could at least be made to fail in a
> "safe" way for users who aren't aware of the change.

That's nice and all, but I see no actual patch that implements that, or 
even a proposal with pseudocode. I'm sure there are better ways, but 
till someone actually takes the time to cook up a patch instead of 
handwaving, the situation won't change.

Re: Kernel recipes with broken PRs now

[Phil Blundell]

On Sun, 2009-05-24 at 13:37 +0200, Koen Kooi wrote:
> On 24-05-09 11:23, Phil Blundell wrote:
> >  This seems
> > particularly pertinent for the stable branch where, as I understood it,
> > intrusive changes were supposed to be avoided.
> 
> Wrong, the stable branch can get intrusive changes as well, the only 
> prereq is review and testing, which most changes in .dev never get.

Fair enough.  "Stable" seems like a bit of a misnomer in that case, but
if this genuinely is the policy for the branch then so be it.

> That's nice and all, but I see no actual patch that implements that, or 
> even a proposal with pseudocode. I'm sure there are better ways, but 
> till someone actually takes the time to cook up a patch instead of 
> handwaving, the situation won't change.

I did already propose one specific better way (i.e. extending the
kernel-abiversion mechanism) in which you could have implemented the
original feature.  I see that Richard Purdie also made some different
suggestions in response to your original RFC.  If these suggestions
don't work for you, please explain why not and perhaps we can come up
with something different.

I have also suggested one way in which, if you aren't prepared to solve
the underlying problem in a better way, you could at least mitigate the
effect of the collateral damage (i.e. making your change be DISTRO
opt-in rather than globally applied).

It seems fairly clear that, as the originator of the patch in question,
the onus is on you to minimise any resulting damage to other users.
Simply checking in something that breaks the versioning for all kernels
apart from your own and then expecting other people to run around after
you cleaning up the mess that you've created is, at the very least,
inconsiderate.

p.

Re: Kernel recipes with broken PRs now

[Koen Kooi]

On 24-05-09 14:27, Phil Blundell wrote:

> It seems fairly clear that, as the originator of the patch in question,
> the onus is on you to minimise any resulting damage to other users.

I'm gradually fixing kernel as I encounter them, but since I don't have 
access to all hardware present in OE, or computing power to test all 
toolchain permutations needed to build all kernels (e.g. kernels 
requiring gcc 2.93.3), I am currently limiting that effort to kernel I 
can actually test.
Furthermore, only kernel actually used by machines present in OE can get 
fixed, we have a number of kernels that have recipes, but no machines 
using them.

regards,

Koen

Re: Kernel recipes with broken PRs now

[Phil Blundell]

On Sun, 2009-05-24 at 15:04 +0200, Koen Kooi wrote:
> On 24-05-09 14:27, Phil Blundell wrote:
> 
> > It seems fairly clear that, as the originator of the patch in question,
> > the onus is on you to minimise any resulting damage to other users.
> 
> I'm gradually fixing kernel as I encounter them, but since I don't have 
> access to all hardware present in OE, or computing power to test all 
> toolchain permutations needed to build all kernels (e.g. kernels 
> requiring gcc 2.93.3), I am currently limiting that effort to kernel I 
> can actually test.

In situations like this there are still steps you can reasonably take to
manage the impact on other people, even if you can't directly test all
the potentially-affected packages for yourself.  

In cases like the one at hand here, it's fairly straightforward to
consider what would happen to recipes and machines which haven't been
modified and ensure that the answer isn't anything undesirable.  If it
isn't practical to do that (because the change is more complex and the
interactions are hard to foresee), or if the answer is that something
bad will happen but you don't know how to fix it, you can arrange for
your patch to only take effect for DISTROs that have explicitly selected
it in order to limit the risk for others.

> Furthermore, only kernel actually used by machines present in OE can
> get fixed, we have a number of kernels that have recipes, but no
> machines using them.

That does seem like another indication that this enforced 1:1 mapping
between kernels and MACHINEs is not a good idea in general.  If I
remember right there are at least a few machines which have many-to-many
mappings here and it's hard to see how a MACHINE_KERNEL_PR variable can
really work in that situation.

p.

Re: Kernel recipes with broken PRs now

[Leon Woestenberg]

Hello all,

On Sun, May 24, 2009 at 11:23 AM, Phil Blundell <philb@gnu.org> wrote:
> On Sun, 2009-05-24 at 10:23 +0200, Koen Kooi wrote:
>> Now, if people posting in this thread would bother to read the original
>> RFC (that got approved for .dev as well as stable/2009), we wouldn't be
>> having this discussion.
>
> I guess the RFC in question is this one:
>
> http://projects.linuxtogo.org/pipermail/openembedded-devel/2009-April/009578.html
>
> but it doesn't seem to really address the issues that have been raised
> in this thread.  Indeed, looking at the responses that were posted to
> the original RFC it doesn't seem at all obvious that there was a
> consensus in favour of the patch; Otavio Salvador said that he was
> "fully support[ive]" of it, but everybody else who posted seemed to have
> some or other reservations.
>

Can we use [HEADS UP] in the subject line when an intrusive patch has
landed in .dev, apart from the RFC?

I will write a RFC for this one. :-)

Regards,
-- 
Leon

Re: Kernel recipes with broken PRs now

[Marcin Juszkiewicz]

Dnia piątek, 22 maja 2009 o 23:31:43 Tom Rini napisał(a):
> Hey all.  With the MACHINE_KERNEL_PR stuff, the following recipes
> will now revert to r0 rather than:

One solution is to set PR after 'inherit kernel'. But thats workaround.

Other would be checking is MACHINE_KERNEL_PR != 'r0' and use it as PR.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: Kernel recipes with broken PRs now

[Tom Rini]

On Sun, May 24, 2009 at 08:49:29PM +0200, Marcin Juszkiewicz wrote:
> Dnia pi??tek, 22 maja 2009 o 23:31:43 Tom Rini napisa??(a):
> > Hey all.  With the MACHINE_KERNEL_PR stuff, the following recipes
> > will now revert to r0 rather than:
> 
> One solution is to set PR after 'inherit kernel'. But thats workaround.

Perhaps this isn't so much a workaround but an opt-out ?  The more I
think about it, while this is a useful mechanism for machines that need
it, it's also a PITA for machines that don't (now you need to modify
your kernel recipe and bump something in your machine.conf, meaning full
cache rebuild just for a feature you aren't even using).  Comments?  I'm
tempted to just do that re-org next weekend, if no one beats me to it.

-- 
Tom Rini

Re: Kernel recipes with broken PRs now

[Koen Kooi]

On 30-05-09 21:16, Tom Rini wrote:
> while this is a useful mechanism for machines that need
> it, it's also a PITA for machines that don't

Every machine needs it, since every machine can have external modules 
(or kernel dependant userspace apps). So stating that "some machines" 
need it is plain wrong.

regards,

Koen

Re: Kernel recipes with broken PRs now

[Tom Rini]

On Sat, May 30, 2009 at 11:13:01PM +0200, Koen Kooi wrote:
> On 30-05-09 21:16, Tom Rini wrote:
>> while this is a useful mechanism for machines that need
>> it, it's also a PITA for machines that don't
>
> Every machine needs it, since every machine can have external modules  
> (or kernel dependant userspace apps). So stating that "some machines"  
> need it is plain wrong.

Every machine might be able to make use of it, if it either depends on
unstable / in development programs or modules, OR it can use some
external kernel module (IMHO the right answer for this is versioned
dependancies, having the PR be increasing from 2.6.29 to 2.6.30 is
different than normal behavior).  This isn't always going to be an
option.

-- 
Tom Rini

Re: Kernel recipes with broken PRs now

[Otavio Salvador]

Hello Tom,

On Sat, May 30, 2009 at 6:33 PM, Tom Rini <trini@embeddedalley.com> wrote:
[...]
> Every machine might be able to make use of it, if it either depends on
> unstable / in development programs or modules, OR it can use some
> external kernel module (IMHO the right answer for this is versioned
> dependancies, having the PR be increasing from 2.6.29 to 2.6.30 is
> different than normal behavior).  This isn't always going to be an
> option.

I agree that a versioned dependency would be the optimal solution for
it, even better would be if we could use ABI versions for those
depends (somewhat as done for X packages in Debian) however AFAIK
bitbake doesn't support it yet, does it?

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: Kernel recipes with broken PRs now

[Tom Rini]

On Sat, May 30, 2009 at 07:16:29PM -0300, Otavio Salvador wrote:
> Hello Tom,
> 
> On Sat, May 30, 2009 at 6:33 PM, Tom Rini <trini@embeddedalley.com> wrote:
> [...]
> > Every machine might be able to make use of it, if it either depends on
> > unstable / in development programs or modules, OR it can use some
> > external kernel module (IMHO the right answer for this is versioned
> > dependancies, having the PR be increasing from 2.6.29 to 2.6.30 is
> > different than normal behavior).  This isn't always going to be an
> > option.
> 
> I agree that a versioned dependency would be the optimal solution for
> it, even better would be if we could use ABI versions for those
> depends (somewhat as done for X packages in Debian) however AFAIK
> bitbake doesn't support it yet, does it?

No, it does not.

-- 
Tom Rini

Re: Kernel recipes with broken PRs now

[Phil Blundell]

On Sat, 2009-05-30 at 12:16 -0700, Tom Rini wrote:
> On Sun, May 24, 2009 at 08:49:29PM +0200, Marcin Juszkiewicz wrote:
> > Dnia pi??tek, 22 maja 2009 o 23:31:43 Tom Rini napisa??(a):
> > > Hey all.  With the MACHINE_KERNEL_PR stuff, the following recipes
> > > will now revert to r0 rather than:
> > 
> > One solution is to set PR after 'inherit kernel'. But thats workaround.
> 
> Perhaps this isn't so much a workaround but an opt-out ?  The more I
> think about it, while this is a useful mechanism for machines that need
> it, it's also a PITA for machines that don't (now you need to modify
> your kernel recipe and bump something in your machine.conf, meaning full
> cache rebuild just for a feature you aren't even using).  Comments?  I'm
> tempted to just do that re-org next weekend, if no one beats me to it.

Yes, I agree that this is a PITA for machines (or, maybe more
accurately, distros) that don't want it.  As I wrote before, the
underlying problem is a legitimate one but, as currently implemented,
MACHINE_KERNEL_PR seems like a fairly poor solution to it.

My personal preference would still be just to make MACHINE_KERNEL_PR be
an opt-in thing per DISTRO.  I guess angstrom wants this: are there any
other distros that do?

p.

Re: Kernel recipes with broken PRs now

[Otavio Salvador]

Hello,

On Sat, May 30, 2009 at 8:04 PM, Phil Blundell <philb@gnu.org> wrote:
> My personal preference would still be just to make MACHINE_KERNEL_PR be
> an opt-in thing per DISTRO.  I guess angstrom wants this: are there any
> other distros that do?

My understand is that every distro that uses anything that needs ABI
compatibility with kernel needs it, or is suppose to use it. By ABI
compatibility I mean:

 - external kernel modules
 - binaries that require not stable symbols in kernel

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: Kernel recipes with broken PRs now

[Phil Blundell]

On Sat, 2009-05-30 at 21:49 -0300, Otavio Salvador wrote:
> Hello,
> 
> On Sat, May 30, 2009 at 8:04 PM, Phil Blundell <philb@gnu.org> wrote:
> > My personal preference would still be just to make MACHINE_KERNEL_PR be
> > an opt-in thing per DISTRO.  I guess angstrom wants this: are there any
> > other distros that do?
> 
> My understand is that every distro that uses anything that needs ABI
> compatibility with kernel needs it, or is suppose to use it.

As I understand it, the situation that MACHINE_KERNEL_PR is meant to fix
is where both the following are true:

1) you have an external package (be that an out-of-tree module or some
other binary) which depends on some detail of the kernel ABI; and

2) the ABI in question is in fact changing, necessitating a rebuild,
even though the advertised ABI version (what we save in
kernel-abiversion) isn't

Emperically, since most DISTROs have been managing fine without
MACHINE_KERNEL_PR until now, it seems that either this situation isn't
arising very often in practice or the maintainers are managing to work
around it in some other way.  Whichever of those is the case, the need
for a solution to this problem doesn't seem to be very acute right
now.  

Further, it seems clear that the MACHINE_KERNEL_PR approach, as
currently implemented, has at least a few deficiencies:

a) it will cause PR to go backwards for kernel packages which haven't
been updated to match, and this will happen silently so the maintainers
may not realise at first what is going on;

b) it doesn't scale very well to the situation where you have either a
single kernel used by multiple MACHINEs, or a single MACHINE with
multiple kernels.  I suspect the former might be the case for some of
the ipaqs, and I'm fairly sure that the latter can be the case for some
models of zaurus.

c) it causes the kernel metadata to be scattered around the tree in a
slightly weird way, rather than localised to the kernel's own .bb file
where it arguably belongs.

d) it requires a rebuild of all out-of-tree modules for any kernel
change at all, even if the ABI was unaffected.

Now, none of these deficiencies are absolutely intolerable, and it's
perfectly understandable that some distro maintainers might decide to
put up with them in order to gain the perceived benefits of
MACHINE_KERNEL_PR.  But, for DISTROs and/or MACHINEs that weren't
suffering from the original problem in the first place, this patch will
simply introduce annoyances with no compensating benefits.

I think it would be quite possible to write a patch to fix the original
problems without introducing the deficiencies above, and if that were
done then there should be no downsides to enabling the patch globally.
But, as it stands today, I don't think that MACHINE_KERNEL_PR is
something that should be foisted on folks who don't want or need it.

p.