On 06/23/2011 07:39 PM, Somebody in the thread at some point said:
I mentioned this already to npitre but for various reasons we are planning to
target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has
some known issues like no onboard audio or HDMI audio, but since 3.0 has a new
and better ALSA implementation for Panda I'm not sure it's worth spending time
on when the old implementation won't really go into linux-linaro even if we
did forward-port it again.
$ git diff --shortstat v2.6.39..linaro-2.6.39 sound/
158 files changed, 20097 insertions(+), 6899 deletions(-)
$ git diff --shortstat linaro-2.6.39..v3.0-rc4 sound/
65 files changed, 4586 insertions(+), 3612 deletions(-)
So please lets stop that "linaro-2.6.39 is just 2.6.39" rhetoric when
numbers show that linaro-2.6.39 is much closer to the strictly
speaking still nonexistent 3.0 than 2.6.39.
Well, I don't think it is rhetoric, I am not trying to make any point or
suggest you should do anything different. I'm not sure what I can take
from the gross diffstat number anyway, it could mean a few things from
"holy crap they changed the APIs totally" to "oh they fixed a lot of
spelling mistakes".
I was just noting - because sound didn't seem to come up on .39 - that
the situation is the same if:
a) you have a chunk of something coming from behind like .35 as the .38
Panda onboard Alsa stuff was, and it carries with it deps on changes to
core code that are likely to upset other SoC files on there, or
b) you have a chunk of something coming from ahead (and there is meant
to be shiny new Alsa Panda support in HEAD) backporting and it too has
deps on newer core stuff that if it was brought in, would also upset the
other Soc files on there who are still coded against older core APIs.
Yes it can be straightened out but I ask myself is that what I should be
doing instead of the stuff I am doing. I guess that is to the point of
the philosophical questions you are asking later in this mail.
In fact tomorrow I will be on a call and the question will come, "is
there a 11.10 Panda kernel tree for us to package yet?" and since they
told they want a 3.0 result, "yes a 3.0 tracking branch is started and
pretty workable already" is the right answer compared to one involving
the number 39. I realize that's not really fair considering you kitted
your tree out with so much stuff from the future but that is an accurate
assessment I think.
I'm seriously starting to question the usefulness of the "Linaro" kernel
tree in fact. For one year that I've been putting such a tree together,
the feedback and response have been less than overwhelming. The idea
was to _consolidate_ the work that the various groups within Linaro was
producing into a single and coherent whole without screwing up the other
groups' work, but so far this hasn't been a great success for various
reasons.
Well this job is very tough.
What stopped more being usable from our stuff was DSS contamination risk
on OMAP3, since the bits of DSS not already upstream have been a
continuing challenge to us to even understand let alone fix; and
trailing entrails from uplevelled chunks leaking into common core code.
In short once the goodies upstream run out (but to be fair TI has a huge
amount of goodies upstream), our LT tree anyway has this foaming crud of
uplevelled, known-deprecated and BSP-type patches from unknown upstream
trees frozen in time. That is not the ideal raw material for what
you're trying to do.
I expect it can be that we can do a bit better in the next months in
terms of tighter integration with vendor "topic repo" sources directly,
and get a somewhat more wholesome tree.
So I'm asking people for comments about this tree.
- Is this useful?
- Is it important?
- Are _you_ using it?
Well I am using it and intend to continue. Ubuntu are using it for
Panda via that path too.
- Is solving the ARM fragmentation problem still a Linaro priority?
- Is the Linaro kernel effective for this?
Half a year ago when I did ask for comments about the usefulness of the
linaro-next tree, I got almost no responses as I suspected, and I
therefore dropped that tree to concentrate my efforts on the Linaro
"stable" branches. If even the stable branch doesn't steer more
interest than it does now then this effort is just wasted. Either our
process is to blame, our priorities are wrong, or some efforts are
diverted where they shouldn't.
No not at all, I reiterate there's no message you ought to do something
different from me. In fact, I am hoping for linux-linaro-3.0 to appear
and we go back to basing on that as before.
One reason for the Linaro tree was to help LTs moving ahead rather than
sticking to ancient kernels. Now it seems that everyone wants to get
ahead of the actual latest release from kernel.org which is a radical
shift. Does this mean that vendors and co now are getting used to the
upstream pace and they're going to move to a rebasing workflow for real,
or they're just fooled by the marketing prospects of a meaningless major
kernel version bump? If the former that would be wonderful and maybe the
Linaro kernel outlived its usefulness. If the later... well... what can
I say here?
Well I think you may be right with it being the latter this time, in
which case we shouldn't read too much into it.
In any case that doesn't make a strong case for the "Linaro" kernel.
We could as well just patch the latest Ubuntu kernel, the latest Android
kernel, or whatever existing distro or vendor kernel, in order to
showcase the Linaro initiated work and results. In practice that's what
I see people doing right now anyway. Pushing that work into mainline is
what matters the most in the end, and _that_ should always be Linaro's
top priority.
I don't feel compelled to fight for the survival of the Linaro kernel
either if it is not widely used and significantly useful. I'm more
effective fighting with mainline kernel people: it is much more
interesting and useful with lasting results.
I think a multi- LT branch integration into a single tree has a lot of
value, it is just really tough to ever get even near 100% in terms of
what you can take. But as happened earlier you were able to pull the
whole tilt.39, admittedly it's cheating a bit because there was no sound
meddling of SGX in there to mess it up. But you can read from that you
are dependent on the quality of the contributor LT branches in how far
you can succeed to integrate.
Unfortunately we're not always all that in control of the quality of
that but I think it will generally get better on our side anyway.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
