On Sat, Oct 30, 2010 at 11:18 AM, Elvis Dowson <[email protected]> wrote:
> Hi,
> ? ? ? I was wondering what the long term implications of android development being forked from the linux mainline are?
>
> Android support was removed from 2.6.33 onwards, and development still continues for 2.6.35, by reverting the commit that deleted android from the mainline.
>
> One could argue that android gave linux a solid boost widespread adoption for mobile embedded devices, and its use would continue to grow exponentially with time, more than plain vanilla linux for embedded devices.
>
> Was removing android from the linux kernel mainline a mistake, in retrospect?
Might be your point is true but,if one see the amount of code that
went in main line or tried to push to main line is mere.Thats
unfortunate.
http://www.kroah.com/log/linux/android-kernel-problems.html
Regards,
Ram.
On Tue, Nov 02, 2010 at 02:25:31PM -0700, Janakiram Sistla wrote:
> On Sat, Oct 30, 2010 at 11:18 AM, Elvis Dowson <[email protected]> wrote:
> > Hi,
> > ? ? ? I was wondering what the long term implications of android development being forked from the linux mainline are?
> >
> > Android support was removed from 2.6.33 onwards, and development still continues for 2.6.35, by reverting the commit that deleted android from the mainline.
> >
> > One could argue that android gave linux a solid boost widespread adoption for mobile embedded devices, and its use would continue to grow exponentially with time, more than plain vanilla linux for embedded devices.
> >
> > Was removing android from the linux kernel mainline a mistake, in retrospect?
Are you willing to maintain the android kernel code in the mainline
kernel tree? If so, I will be glad to add it back in, but as no one was
willing to do the work, it was removed. It's as simple as that.
thanks,
greg k-h
On Sat, Nov 06, 2010 at 11:12:02AM -0700, Greg KH wrote:
> Are you willing to maintain the android kernel code in the mainline
> kernel tree? If so, I will be glad to add it back in, but as no one was
> willing to do the work, it was removed. It's as simple as that.
Note that whoever needs maintain the Android kernel code in mainline
needs to be working with both the Android kernel developers as well as
the upstream maintainers, in hopes of finding a way to find a path
which meets the requirements of both the android kernel developers and
the upstream kernel maintainers.
Otherwise, it's highly likely that no forward progress will get made,
and the code will get yanked from staging after 6-9 months of no
forward progress.
Given that the Android kernel developers have already spent upwards of
ten times the amount of engineering hours it would take forward port
their kernel patches to each upstream kernel version for the next
several years, finding a path that meets their requirements as well as
those of the upstream kernel maintainers may not be a trivial thing.
Also keep in mind that someone no less than Linus Torvalds has said
that sometimes forks are good, and that the _freedom_ to fork is
critical. But if anyone feels that figuring out some way to make the
android kernel patches (a) upstreamable, and (b) compatible with
android's userspace is their itch to scratch, the other part of the
open source ethos is that they are certainly free to try.
- Ted
P.S. I speak for myself, and not for my employer.
I think you need to see this: https://review.source.android.com/#change,18761
And this: http://galaxytab.samsungmobile.com/
On Sat, Nov 06, 2010 at 03:22:59PM -0400, Ted Ts'o wrote:
> Given that the Android kernel developers have already spent upwards of
> ten times the amount of engineering hours it would take forward port
> their kernel patches to each upstream kernel version for the next
> several years, finding a path that meets their requirements as well as
> those of the upstream kernel maintainers may not be a trivial thing.
>
> Also keep in mind that someone no less than Linus Torvalds has said
> that sometimes forks are good, and that the _freedom_ to fork is
> critical. But if anyone feels that figuring out some way to make the
> android kernel patches (a) upstreamable, and (b) compatible with
> android's userspace is their itch to scratch, the other part of the
> open source ethos is that they are certainly free to try.
As per the Rusty Russell rule of lkml etiquette, we are all allowed to
participate, or start, one massive, no-holds-barred, ugly as mud flame
war per year. Remembering that the year was going to be over soon and I
didn't think I had met my quota for this yet, I started to respond to
this email.
But after composing it, I realized that it was not going to change
anyone's feelings about the manner, nor cause anything constructive to
ever occur, besides giving zillions of electrons something to do
lighting up /. comment threads. So I've deleted it, and will just
respond with this simple line:
I respectively disagree with your opinion, so we will have to just
agree to disagree at the moment.
The carrots need to be pulled from the garden now, before the next rain
sets in up here in the Pacific northwest, turning them into orange and
purple mush, so I'll go do that, getting my hands dirty with real dirt,
instead of wearing out my fingertips in creating virtual mud here.
cordially,
greg k-h
On Sat, Nov 06, 2010 at 09:40:34PM +0200, Anca Emanuel wrote:
> I think you need to see this: https://review.source.android.com/#change,18761
> And this: http://galaxytab.samsungmobile.com/
What about them? Yes, the Android developers are pushing changes to
mainstream where it makes sense; they were doing this before the
wakelocks contrversy, and they're continuing to do it now. But in the
case of wakelocks, it may be that it's going to have to be a case of
"agree to disagree".
All distributions, including Red Hat and SLES has in the shipped
product with patches that have never hit mainstream, and in some
cases, will never get merged with mainstream. A good example in the
past was the 4G/4G patch. Another one, which is still on-going, is
the Systemtap/utrace patches. Yet no one is killing megawatts worth
of electrons about how Red Hat and SLES are forking the kernel. They
push patches upstream where they can, and where they can't --- they do
what they need to do to satisify and delight their customers.
(Heck, Sony is still using a 2.2 kernel for some of their products
with a huge bunch of patches and no one is toasting them for forking
the kernel....)
Move along, there's nothing to see. Other that money for
journalists/bloggers who are gunning for advertising clicks by
whipping up controversy where IMHO, none deserves to exist.
- Ted
On Sat, Nov 6, 2010 at 12:40 PM, Anca Emanuel <[email protected]> wrote:
> I think you need to see this: https://review.source.android.com/#change,18761\
I have point here all the vendors working on Android are now targeting
their so called open source maintance only targeted towards kernel
maintained on Googles code base git.android.kernel.org.
For example for the same above kernel/tegra ,compare the board
files(board-harmony.c) from same vendor in android.kernel.org
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=arch/arm/mach-tegra/board-harmony.c;h=9e305de56be9ac28ab023dbfc4f748c5f260bec1;hb=f6f94e2ab1b33f0082ac22d71f66385a60d8157f
and in mainline kernel.org for the same vendor board file I see
http://android.git.kernel.org/?p=kernel/tegra.git;a=history;f=arch/arm/mach-tegra/board-harmony.c;h=ee01dd0ae7cd16ae6d207a540d875d3516d53797;hb=linux-tegra-2.6.36
This i dont really understand why.This is the same in case of other
key chipset vendors.
> And this: http://galaxytab.samsungmobile.com/
The above link yes a samsung galaxy tab is an android product so ??
Thanks and regards,
Ram
>
On Sat, 6 Nov 2010, Ted Ts'o wrote:
> On Sat, Nov 06, 2010 at 09:40:34PM +0200, Anca Emanuel wrote:
>> I think you need to see this: https://review.source.android.com/#change,18761
>> And this: http://galaxytab.samsungmobile.com/
>
> What about them? Yes, the Android developers are pushing changes to
> mainstream where it makes sense; they were doing this before the
> wakelocks contrversy, and they're continuing to do it now. But in the
> case of wakelocks, it may be that it's going to have to be a case of
> "agree to disagree".
>
> All distributions, including Red Hat and SLES has in the shipped
> product with patches that have never hit mainstream, and in some
> cases, will never get merged with mainstream. A good example in the
> past was the 4G/4G patch. Another one, which is still on-going, is
> the Systemtap/utrace patches. Yet no one is killing megawatts worth
> of electrons about how Red Hat and SLES are forking the kernel. They
> push patches upstream where they can, and where they can't --- they do
> what they need to do to satisify and delight their customers.
>
> (Heck, Sony is still using a 2.2 kernel for some of their products
> with a huge bunch of patches and no one is toasting them for forking
> the kernel....)
the difference is that these other patches that you are talking about do
not result in incompatible userspace (or at least, they don't except for
very specialied apps).
also, none of these other patches resulted in device drivers developed for
a distro being incompatible with mainline.
I think that the concerns from technical folks (as opposed to
journalists/bloggers) would go down drastically if there was some
acceptable way for the incompatible bits (like wakelocks) could be
stubbed out so that the rest of the things could be moved easily.
David Lang
> Move along, there's nothing to see. Other that money for
> journalists/bloggers who are gunning for advertising clicks by
> whipping up controversy where IMHO, none deserves to exist.
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sat, Nov 06, 2010 at 04:52:26PM -0700, [email protected] wrote:
> also, none of these other patches resulted in device drivers
> developed for a distro being incompatible with mainline.
What, people can't delete a couple of single lines of code before
submitting the device driver upstream to mainline? Here's the world's
tiniest violin playing, "my heart bleeds for you"....
> I think that the concerns from technical folks (as opposed to
> journalists/bloggers) would go down drastically if there was some
> acceptable way for the incompatible bits (like wakelocks) could be
> stubbed out so that the rest of the things could be moved easily.
That was offerred as an interim/temporary solution, but no one seems
willing to commit that those stubs exist permanently. At best, for
another 6-9 months before they would be yanked out again, which would
spur more fodder for the journalists/bloggers.
Personally, I would think that temporary stubs would be really bad,
raw deal for the Android team. It would force them through another
set of hundreds of manhours worth of discussions (my folder with these
discussions is currently 10 megabytes of e-mail; given that there seem
to be irroncilable differences with respect to philosophy, and perhaps
outright commercial incentives that the Android approach not go in by
some of the participants, I have very little personal hope that more
talks would go anywhere), and then after 6-9 months, it would be, "no
forward progress", followed by the stubs getting yanked from the
kernel, followed by more rounds of misinformed articles written by the
tech tabloid community.
Why would this be a good deal for anybody?
- Ted
On Sat, 6 Nov 2010 20:03:48 -0400
"Ted Ts'o" <[email protected]> wrote:
> On Sat, Nov 06, 2010 at 04:52:26PM -0700, [email protected] wrote:
> > also, none of these other patches resulted in device drivers
> > developed for a distro being incompatible with mainline.
>
> What, people can't delete a couple of single lines of code before
> submitting the device driver upstream to mainline?
I've always wondered that but never seen a good answer from the Android
people as to why they don't push the stuff without the wakelock bits and
just keep "add wakelock" patches for those as they do for the core kernel
stuff they hack about.
On Sat, 6 Nov 2010, Ted Ts'o wrote:
> On Sat, Nov 06, 2010 at 04:52:26PM -0700, [email protected] wrote:
>> also, none of these other patches resulted in device drivers
>> developed for a distro being incompatible with mainline.
>
> What, people can't delete a couple of single lines of code before
> submitting the device driver upstream to mainline? Here's the world's
> tiniest violin playing, "my heart bleeds for you"....
the problem is that wouldn't be the version that would be maintained.
>> I think that the concerns from technical folks (as opposed to
>> journalists/bloggers) would go down drastically if there was some
>> acceptable way for the incompatible bits (like wakelocks) could be
>> stubbed out so that the rest of the things could be moved easily.
>
> That was offerred as an interim/temporary solution, but no one seems
> willing to commit that those stubs exist permanently. At best, for
> another 6-9 months before they would be yanked out again, which would
> spur more fodder for the journalists/bloggers.
>
> Personally, I would think that temporary stubs would be really bad,
> raw deal for the Android team. It would force them through another
> set of hundreds of manhours worth of discussions (my folder with these
> discussions is currently 10 megabytes of e-mail; given that there seem
> to be irroncilable differences with respect to philosophy, and perhaps
> outright commercial incentives that the Android approach not go in by
> some of the participants, I have very little personal hope that more
> talks would go anywhere), and then after 6-9 months, it would be, "no
> forward progress", followed by the stubs getting yanked from the
> kernel, followed by more rounds of misinformed articles written by the
> tech tabloid community.
>
> Why would this be a good deal for anybody?
Doing temporary stubs would be really bad for all the reasons you state.
That's why I said that the stubs would have to be acceptable to everyone.
they will be in there for a long time, and would probably end up being
used in other drivers (ones that are in mainline now) so that they could
used by android.
unfortunantly this is not something that has been acceptable upstream. I
understand the reluctance for this (and the disaster we would have if
things like this happened frequently), I just wonder if being able to get
the drivers for phones in mainline may be worth the maintinance overhead
of allowing these stubs permanently in mainline
David Lang
On Sat, Nov 6, 2010 at 5:13 PM, Alan Cox <[email protected]> wrote:
> On Sat, 6 Nov 2010 20:03:48 -0400
> "Ted Ts'o" <[email protected]> wrote:
>
>> On Sat, Nov 06, 2010 at 04:52:26PM -0700, [email protected] wrote:
>> > also, none of these other patches resulted in device drivers
>> > developed for a distro being incompatible with mainline.
>>
>> What, people can't delete a couple of single lines of code before
>> submitting the device driver upstream to mainline?
>
> I've always wondered that but never seen a good answer from the Android
> people as to why they don't push the stuff without the wakelock bits and
> just keep "add wakelock" patches for those as they do for the core kernel
> stuff they hack about.
>
I think the developers target for andriod kernel more than the
mainline.The biggest point of the hour is whether the device works for
Android Eclair, Android Froyo and not the see their patches in linux
kernel unfortunately.
Regards,
Ram.
On Sat, 6 Nov 2010 16:09:44 -0700 Greg KH wrote:
> As per the Rusty Russell rule of lkml etiquette, we are all allowed to
> participate, or start, one massive, no-holds-barred, ugly as mud flame
> war per year. Remembering that the year was going to be over soon and I
> didn't think I had met my quota for this yet, I started to respond to
> this email.
>
> But after composing it, I realized that it was not going to change
> anyone's feelings about the manner, nor cause anything constructive to
> ever occur, besides giving zillions of electrons something to do
> lighting up /. comment threads. So I've deleted it, and will just
ack
> respond with this simple line:
>
> I respectively disagree with your opinion, so we will have to just
> agree to disagree at the moment.
>
> The carrots need to be pulled from the garden now, before the next rain
> sets in up here in the Pacific northwest, turning them into orange and
> purple mush, so I'll go do that, getting my hands dirty with real dirt,
> instead of wearing out my fingertips in creating virtual mud here.
heh, you had me for a moment there. I thought that you were referring
to harvesting virtual carrots from the android stuff.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
HI Greg,
On Nov 6, 2010, at 10:12 PM, Greg KH wrote:
> Are you willing to maintain the android kernel code in the mainline
> kernel tree? If so, I will be glad to add it back in, but as no one was
> willing to do the work, it was removed. It's as simple as that.
I'm willing to do this. I'll start off initially with support for TI OMAP 35xx
and TI OMAP 4440, build and test initially on the Gumstix Overo,
BeagleBoard and PandaBoard.
I'll start with v2.6.37-rc1 and android-froyo-2.2, and try to do the required
changes to get it accepted into mainline by v2.6.39.
Elvis Dowson
On Sun, Nov 7, 2010 at 10:38 AM, Elvis Dowson <[email protected]> wrote:
> HI Greg,
>
> On Nov 6, 2010, at 10:12 PM, Greg KH wrote:
>
>> Are you willing to maintain the android kernel code in the mainline
>> kernel tree? ?If so, I will be glad to add it back in, but as no one was
>> willing to do the work, it was removed. ?It's as simple as that.
>
> I'm willing to do this. I'll start off initially with support for TI OMAP 35xx
> and TI OMAP 4440, build and test initially on the Gumstix Overo,
> BeagleBoard and PandaBoard.
>
> I'll start with v2.6.37-rc1 and android-froyo-2.2, and try to do the required
> changes to get it accepted into mainline by v2.6.39.
>
> Elvis Dowson
Read this: https://wiki.linaro.org/Releases/1105?action=AttachFile&do=get&target=Linaro+Cycle+2+Requirements+18+September+2010.pdf
( http://is.gd/gNP7y )
[quote]
Android Strategy
Sponsor: Yves V. (Freescale)
Leads: Lo?c, Scott B.
WGs: Kernel Consolidation, Toolchain
...
A2.2 Support upstreaming of Android patches
[/quote]
Linaro is going in the same direction.
On Sun, Nov 07, 2010 at 01:44:45PM +0200, Anca Emanuel wrote:
> On Sun, Nov 7, 2010 at 10:38 AM, Elvis Dowson <[email protected]> wrote:
> > HI Greg,
> >
> > On Nov 6, 2010, at 10:12 PM, Greg KH wrote:
> >
> >> Are you willing to maintain the android kernel code in the mainline
> >> kernel tree? ?If so, I will be glad to add it back in, but as no one was
> >> willing to do the work, it was removed. ?It's as simple as that.
> >
> > I'm willing to do this. I'll start off initially with support for TI OMAP 35xx
> > and TI OMAP 4440, build and test initially on the Gumstix Overo,
> > BeagleBoard and PandaBoard.
> >
> > I'll start with v2.6.37-rc1 and android-froyo-2.2, and try to do the required
> > changes to get it accepted into mainline by v2.6.39.
> >
> > Elvis Dowson
>
> Read this: https://wiki.linaro.org/Releases/1105?action=AttachFile&do=get&target=Linaro+Cycle+2+Requirements+18+September+2010.pdf
> ( http://is.gd/gNP7y )
>
> [quote]
> Android Strategy
> Sponsor: Yves V. (Freescale)
> Leads: Lo?c, Scott B.
> WGs: Kernel Consolidation, Toolchain
> ...
>
> A2.2 Support upstreaming of Android patches
> [/quote]
>
> Linaro is going in the same direction.
That does not mean they will actually ever get to that work, or achieve
it...
Hi Greg,
I just saw the presentation you made on the subject for the 2010 CELF Embedded Linux Conference
https://github.com/gregkh/android-presentation/raw/master/android-kernel.pdf
Elvis Dowson
On Mon, Nov 08, 2010 at 12:06:03AM +0400, Elvis Dowson wrote:
> Hi Greg,
> I just saw the presentation you made on the subject for the 2010 CELF Embedded Linux Conference
>
> https://github.com/gregkh/android-presentation/raw/master/android-kernel.pdf
Please see the video of the talk to get the context for the slides.
thanks,
greg k-h
Hi,
On Sun, Nov 7, 2010 at 10:57 AM, Greg KH <[email protected]> wrote:
> [...]
>
Just a small comment to say that Android is not the only one (but
certainly the most visible, and thus easiest to bash on) not making
effort to get their stuff in mainline. OpenWRT people are also
maintaining their fork of the kernel, without even using git, and not
contributing much to mainline (I'm certainly mistaken on that last
comment).
I'm still stuck to use their 2.6.32 to use my AR71xx-based (MIPS)
boards, just this part is +15kloc.
- Arnaud
Hi,
On Sun, Nov 7, 2010 at 4:31 PM, Greg KH <[email protected]> wrote:
> On Mon, Nov 08, 2010 at 12:06:03AM +0400, Elvis Dowson wrote:
>> Hi Greg,
>> ? ? ? ? ? ? ? ? ? I just saw the presentation you made on the subject for the 2010 CELF Embedded Linux Conference
>>
>> https://github.com/gregkh/android-presentation/raw/master/android-kernel.pdf
>
> Please see the video of the talk to get the context for the slides.
>
Say that I somehow hate to complain on large diffusion mailing list :)
- Arnaud
On Sun, Nov 7, 2010 at 4:46 PM, Arnaud Lacombe <[email protected]> wrote:
> Hi,
>
> On Sun, Nov 7, 2010 at 4:31 PM, Greg KH <[email protected]> wrote:
>> On Mon, Nov 08, 2010 at 12:06:03AM +0400, Elvis Dowson wrote:
>>> Hi Greg,
>>> ? ? ? ? ? ? ? ? ? I just saw the presentation you made on the subject for the 2010 CELF Embedded Linux Conference
>>>
>>> https://github.com/gregkh/android-presentation/raw/master/android-kernel.pdf
>>
>> Please see the video of the talk to get the context for the slides.
>>
> Say that I somehow hate to complain on large diffusion mailing list :)
>
Looks I replied to the wrong mail, sorry for that :/
- Arnaud
On Sun, Nov 07, 2010 at 04:44:48PM -0500, Arnaud Lacombe wrote:
> Hi,
>
> On Sun, Nov 7, 2010 at 10:57 AM, Greg KH <[email protected]> wrote:
> > [...]
> >
> Just a small comment to say that Android is not the only one (but
> certainly the most visible, and thus easiest to bash on) not making
> effort to get their stuff in mainline. OpenWRT people are also
> maintaining their fork of the kernel, without even using git, and not
> contributing much to mainline (I'm certainly mistaken on that last
> comment).
Isn't the openwrt stuff just drivers and some arch specific code?
Nothing that is core infrastructure, and nothing preventing them from
submitting the drivers and arch code if they want to, right?
If so, why don't you submit it? Why don't they?
curious,
greg k-h
Hi,
On Sun, Nov 7, 2010 at 4:59 PM, Greg KH <[email protected]> wrote:
> On Sun, Nov 07, 2010 at 04:44:48PM -0500, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Sun, Nov 7, 2010 at 10:57 AM, Greg KH <[email protected]> wrote:
>> > [...]
>> >
>> Just a small comment to say that Android is not the only one (but
>> certainly the most visible, and thus easiest to bash on) not making
>> effort to get their stuff in mainline. OpenWRT people are also
>> maintaining their fork of the kernel, without even using git, and not
>> contributing much to mainline (I'm certainly mistaken on that last
>> comment).
>
> Isn't the openwrt stuff just drivers and some arch specific code?
> Nothing that is core infrastructure, and nothing preventing them from
> submitting the drivers and arch code if they want to, right?
>
>From what I can see, yes.
> If so, why don't you submit it?
>
because I have no knowledge on the code, nor have any documentation on
the underlying hardware. That said, it's in my TODO, but stuff keeps
getting in before this entry.
>Why don't they?
>
I just checked with some dev on IRC, there might be a time issue. The
patches have been synced with 2.6.36 recently (a month ago). So
there're still hope :)
- Arnaud
On Sun, Nov 07, 2010 at 06:09:33PM -0500, Arnaud Lacombe wrote:
> >Why don't they?
> >
> I just checked with some dev on IRC, there might be a time issue. The
> patches have been synced with 2.6.36 recently (a month ago). So
> there're still hope :)
Have a pointer to the patch?
thanks,
greg k-h
Hi,
On Sun, Nov 7, 2010 at 8:42 PM, Greg KH <[email protected]> wrote:
> On Sun, Nov 07, 2010 at 06:09:33PM -0500, Arnaud Lacombe wrote:
>> >Why don't they?
>> >
>> I just checked with some dev on IRC, there might be a time issue. The
>> patches have been synced with 2.6.36 recently (a month ago). So
>> there're still hope :)
>
> Have a pointer to the patch?
>
It is split between new files, under target/linux/ar71xx of their
tree, and patches of existing kernel files. You can browse online the
git export of their SVN:
http://nbd.name/gitweb.cgi?p=openwrt.git;a=tree;f=target/linux/ar71xx;hb=b45b193b99d0111a70845c02bdeb3ece58fb15a1
or clone the git export (~90M):
git://nbd.name/openwrt.git
I guess with some git-fuu, everything can be extracted, so that the
history of the files themselves would be kept, thought, commit message
may need a bit of tweaking. Then patch linking the core to the rest of
the kernel can be applied separately. I'll try to have a look tonight.
- Arnaud
> thanks,
>
> greg k-h
>
Arnaud,
On Sunday 07 November 2010 22:44:48 Arnaud Lacombe wrote:
> Hi,
>
> On Sun, Nov 7, 2010 at 10:57 AM, Greg KH <[email protected]> wrote:
> > [...]
>
> Just a small comment to say that Android is not the only one (but
> certainly the most visible, and thus easiest to bash on) not making
> effort to get their stuff in mainline. OpenWRT people are also
> maintaining their fork of the kernel, without even using git, and not
> contributing much to mainline (I'm certainly mistaken on that last
> comment).
You are a bit rude and mistaking at the same time. We did contribute back TI
AR7, Mikrotik RB532, RDC R-321x, IXP4xx to name a few and a lot of various
patches on different related projects.
So I do agree the situation is not the best because we still maintain too many
patches in the OpenWrt repository, especially since the added value of OpenWrt
do not only resides in the kernel patches for a specific target.
Please understand that we are just human beings and right now, ar71xx is
becoming more and more present on the wireless routers market, that's why
developpers (Imre and Gabor) are being kept busy making this target work fine
on all of the routers out there (and it's not just about 1 or 2 models, we are
talking about nearly 50, all of these with different hardware integration, thus
challenges).
The fact that we are using subversion is purely gratuitous, remember this is
just a tool after all. The flat structure that we have, and the per-kernel
version patches still makes it easy for people to pick whatever they need from
our tree. Certainly this is not ideal, but no major stopper.
>
> I'm still stuck to use their 2.6.32 to use my AR71xx-based (MIPS)
> boards, just this part is +15kloc.
2.6.36 support for ar71xx is out there since Oct 8th.
--
Florian
On Monday 08 November 2010 00:09:33 Arnaud Lacombe wrote:
> Hi,
>
> On Sun, Nov 7, 2010 at 4:59 PM, Greg KH <[email protected]> wrote:
> > On Sun, Nov 07, 2010 at 04:44:48PM -0500, Arnaud Lacombe wrote:
> >> Hi,
> >>
> >> On Sun, Nov 7, 2010 at 10:57 AM, Greg KH <[email protected]> wrote:
> >> > [...]
> >>
> >> Just a small comment to say that Android is not the only one (but
> >> certainly the most visible, and thus easiest to bash on) not making
> >> effort to get their stuff in mainline. OpenWRT people are also
> >> maintaining their fork of the kernel, without even using git, and not
> >> contributing much to mainline (I'm certainly mistaken on that last
> >> comment).
> >
> > Isn't the openwrt stuff just drivers and some arch specific code?
> > Nothing that is core infrastructure, and nothing preventing them from
> > submitting the drivers and arch code if they want to, right?
>
> From what I can see, yes.
>
> > If so, why don't you submit it?
>
> because I have no knowledge on the code, nor have any documentation on
> the underlying hardware. That said, it's in my TODO, but stuff keeps
> getting in before this entry.
>
> >Why don't they?
>
> I just checked with some dev on IRC, there might be a time issue. The
> patches have been synced with 2.6.36 recently (a month ago). So
> there're still hope :)
Of course there is, but like I told you on IRC, the best way to gather
someone's attention is to talk to him. So far, you did not put openwrt-devel
in copy of this thread, you should have, we are not ignoring anyone's request
if made available.
--
Florian
Florian and Greg,
> > Just a small comment to say that Android is not the only one (but
> > certainly the most visible, and thus easiest to bash on) not making
> > effort to get their stuff in mainline. OpenWRT people are also
> > maintaining their fork of the kernel, without even using git, and not
> > contributing much to mainline (I'm certainly mistaken on that last
> > comment).
>
> You are a bit rude and mistaking at the same time. We did contribute back TI
> AR7, Mikrotik RB532, RDC R-321x, IXP4xx to name a few and a lot of various
> patches on different related projects.
I'm speaking as a bystander here, but Lars-Peter Clausen took an enormous
effort to get an entire new SoC, Ingenic's XBurst 4740, into mainline
Linux, using the OpenWrt patch system as his development/staging area.
A lot of that work was merged mainline in 2.6.36, some more is coming.
I think the mainline quality standards are high (nothing wrong with that),
so it's not easy to get stuff up to that level. And there is not exactly
much of a pull force either, if I may say so.
I have worked on numerous projects, platforms and build systems over
the years. The OpenWrt people and tools are some of the most upstream
oriented and best ways to get upstream I have seen.
The next big thing I will try to lend a helping hand to will be the
kernel.org inclusion of the Milkymist SoC.
A fairly clean and constantly re-based kernel is here
https://github.com/tmatsuya/linux-2.6
Linux 2.6.36+ is already booting, now it 'only' needs to go mainline ;-)
http://lists.milkymist.org/pipermail/devel-milkymist.org/2010-October/000979.html
Anybody mainline care to pull directly? That would be awesome. Otherwise
my next best bet would be to go to OpenWrt first, hack it into SVN
patches, then go from there. At least OpenWrt cares a lot to produce
buildable and bootable images at any time, that's an excellent way to
go for bigger and better things.
>From the perspective of someone looking from mainline, I can understand
the frustration over not seeing a git repo that one can pull from at
any time. But from the outside it looks a bit different. Patches are
sometimes forced to live outside mainline for a long long time, years.
And in those years the way OpenWrt is dealing with patches is still a
very effective system to avoid bitrot.
my 2c,
Wolfgang
On Sun, Nov 07, 2010 at 12:13:41AM +0000, Alan Cox wrote:
> I've always wondered that but never seen a good answer from the Android
> people as to why they don't push the stuff without the wakelock bits and
> just keep "add wakelock" patches for those as they do for the core kernel
> stuff they hack about.
Much of this code has other serious issues (eg, code quality or being
written for out of date kernel APIs) which prevents it being merged
without other work.
There are also some other areas where Android introduced random API
variance, though none of them terribly important.
Hi,
Is there an efficient way to locally store all LKML mailing list archives, so that I can efficiently filter on only the android patch review comments?
There must be a hundred thousand emails exchanges that I need to sift through and to locate the discussion threads, and was wondering if there was a more efficient way to go about doing this analysis.
I was thinking of looking at the review comments, incorporating some of the changes, get that reviewed after testing those changes with modified android low-level libraries (I'm guessing mostly android/bionic, but need to check this).
Best regards,
Elvis Dowson
On Tue, Nov 09, 2010 at 10:10:56PM +0400, Elvis Dowson wrote:
> Hi,
> Is there an efficient way to locally store all LKML mailing list
> archives, so that I can efficiently filter on only the android patch
> review comments?
Yes, there are loads of tools that do this. mairix is one that I like
to use to search email archives.
> I was thinking of looking at the review comments, incorporating some
> of the changes, get that reviewed after testing those changes with
> modified android low-level libraries (I'm guessing mostly
> android/bionic, but need to check this).
If you have the rights to make the changes to the andoid userspace code,
great. Otherwise you are not going to get very far.
good luck,
greg k-h
Hi Greg,
On Nov 9, 2010, at 10:24 PM, Greg KH wrote:
> If you have the rights to make the changes to the andoid userspace code,
> great. Otherwise you are not going to get very far.
Isn't the whole Android stack licensed under Apache 2.0? Doesn't everyone
have full access to the android userspace code?
In your slides, you made several references to only google developers being
able to modify the low-level libraries, which I admit I still don't understand.
If we have full access to the source under an Apache 2.0 license, what would
prevent us from making the required modifications and re-releasing the
modified sources under the same Apache 2.0 license?
Best regards,
Elvis Dowson
On Tue, 9 Nov 2010, Elvis Dowson wrote:
> Hi Greg,
>
> On Nov 9, 2010, at 10:24 PM, Greg KH wrote:
>
>> If you have the rights to make the changes to the andoid userspace code,
>> great. Otherwise you are not going to get very far.
>
> Isn't the whole Android stack licensed under Apache 2.0? Doesn't everyone
> have full access to the android userspace code?
>
> In your slides, you made several references to only google developers being
> able to modify the low-level libraries, which I admit I still don't understand.
>
> If we have full access to the source under an Apache 2.0 license, what would
> prevent us from making the required modifications and re-releasing the
> modified sources under the same Apache 2.0 license?
you can modify them, but unless those modifications get used, what good
are they?
David Lang
On Nov 9, 2010, at 10:42 PM, [email protected] wrote:
> you can modify them, but unless those modifications get used, what good are they?
It would at least help us get android into mainline, and allow hand-set manufacturers to
baseline from a newer kernel version, and prevent the fork.
Elvis Dowson
On Tue, Nov 09, 2010 at 10:52:13PM +0400, Elvis Dowson wrote:
>
> On Nov 9, 2010, at 10:42 PM, [email protected] wrote:
>
> > you can modify them, but unless those modifications get used, what good are they?
>
> It would at least help us get android into mainline, and allow
> hand-set manufacturers to baseline from a newer kernel version, and
> prevent the fork.
Ah, but if you make changes to the android userspace that aren't
accepted upstream by the core android development team, you'll be
forking the android userspace. And given that they are continuing to
add new features to the android userspace, what makes you so sure that
the handset manufacturers will follow *your* tree?
Note also that the handset manufacturers also don't want to reveal
choices they may have made vis-a-vis to-be-released hardware until the
product is ready to ship. Hence they make their changes in private
trees that only get shared with partners (including the upstream
Android userspace developers at Google as well as their chip
suppliers) when an NDA is signed.
So it's not clear they will be that interested in using a baseline
from a newer kernel version. Especially if the changes you propose
making to your forked version of the Android userspace don't contain
the latest and greatest user-visible features....
- Ted
P.S. These are my opinions only; I don't speak for my employer.
> Ah, but if you make changes to the android userspace that aren't
> accepted upstream by the core android development team, you'll be
> forking the android userspace. And given that they are continuing to
Oh so forking the kernel is fine but forking userspace is silly. Quaint
> So it's not clear they will be that interested in using a baseline
> from a newer kernel version. Especially if the changes you propose
> making to your forked version of the Android userspace don't contain
> the latest and greatest user-visible features....
Who cares ?
I don't remember IBM and Dell being terribly interested in Linux when it
started but that wasn't a reason not to do it
On Tue, Nov 09, 2010 at 10:32:25PM +0000, Alan Cox wrote:
> > Ah, but if you make changes to the android userspace that aren't
> > accepted upstream by the core android development team, you'll be
> > forking the android userspace. And given that they are continuing to
>
> Oh so forking the kernel is fine but forking userspace is silly. Quaint
I didn't say that it was silly; that was your words. What I said is
that it's not clear any handset manufacturers would pay attention to
the forked android userspace (which was his assumption/hope). Whether
or not it is "silly" depends on what goals are for the original
poster. If he is trying to effect change in terms of how the handset
manufactures do their driver development, then it might not meet his
goals. If he wants to do it for the technical challenge, then of
course he should be encouraged to do whatever give it a go....
I suspect that sometimes we of the LKML community are in danger of
believing our own propaganda, and assume that getting code into
mainline, and developing in mainline is always better than any
alternative, and is higher priority than any other consideration. If
a product had 33% less battery lifetime, but was developed in
mainline, would you buy that over a standard product? OK, maybe a
LKML denizen might. But would most customers?
OTOH, if the original poster thinks that he can develop changes to the
Android userspace that allow the use of an upstream kernel, and has
just as good battery lifetime, and with a system which is just as
debuggable and easy to maintain as the current android userspace, then
by all means, I would love for him to try to prove that he can. And I
will certainly be happy to introduce him to the Android developers who
measure power usage in mobile devices using microwatt meters to see if
he really can do as good of a job using a stock kernel.
So Elvis, if you think you can, please consider this a challenge! :-)
Or if he just wants to get the drivers into mainline so that other
non-Android devices can use those particular chipsets, that's good
too. I just hope that he can do appropriate testing so that he can be
a good maintainer for the drivers, which means testing them. Pushing
code that may or may not work isn't necessarily an improvement!
- Ted
On Tue, 9 Nov 2010 19:35:24 -0500
Ted Ts'o <[email protected]> wrote:
> On Tue, Nov 09, 2010 at 10:32:25PM +0000, Alan Cox wrote:
> > > Ah, but if you make changes to the android userspace that aren't
> > > accepted upstream by the core android development team, you'll be
> > > forking the android userspace. And given that they are continuing to
> >
> > Oh so forking the kernel is fine but forking userspace is silly. Quaint
> OTOH, if the original poster thinks that he can develop changes to the
> Android userspace that allow the use of an upstream kernel, and has
> just as good battery lifetime, and with a system which is just as
> debuggable and easy to maintain as the current android userspace, then
> by all means, I would love for him to try to prove that he can. And I
> will certainly be happy to introduce him to the Android developers who
> measure power usage in mobile devices using microwatt meters to see if
> he really can do as good of a job using a stock kernel.
>
> So Elvis, if you think you can, please consider this a challenge! :-)
>
> Or if he just wants to get the drivers into mainline so that other
> non-Android devices can use those particular chipsets, that's good
> too. I just hope that he can do appropriate testing so that he can be
> a good maintainer for the drivers, which means testing them. Pushing
> code that may or may not work isn't necessarily an improvement!
>
> - Ted
I don't think _maintaining_ a fork is currently necessary or worthwile.
But what could be useful as a proove of concept, would be to try to
express the original wake-lock api (the one that is currently in use on
android) in terms of the mechanisms currently in mainline.
That way, Rafael would probably get useful feedback on
pm_wakeup_event() (and friends) implementation.
Regards,
Flo
On Sat 2010-11-06 20:03:48, Ted Ts'o wrote:
> On Sat, Nov 06, 2010 at 04:52:26PM -0700, [email protected] wrote:
> > also, none of these other patches resulted in device drivers
> > developed for a distro being incompatible with mainline.
>
> What, people can't delete a couple of single lines of code before
> submitting the device driver upstream to mainline? Here's the world's
> tiniest violin playing, "my heart bleeds for you"....
Deleting couple single liners is not a problem. Cleaning up 100KLoC
patch for mainline *is* a problem.
I know, I tried to do that work. Even getting it to staging quality
was hard, and it was recently dropped due to security holes.
Unfortunately google uses wakelocks as an excuse for not cleaning up
stuff... "because readding those few lines would be too hard".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wednesday, November 10, 2010, Pavel Machek wrote:
> On Sat 2010-11-06 20:03:48, Ted Ts'o wrote:
> > On Sat, Nov 06, 2010 at 04:52:26PM -0700, [email protected] wrote:
> > > also, none of these other patches resulted in device drivers
> > > developed for a distro being incompatible with mainline.
> >
> > What, people can't delete a couple of single lines of code before
> > submitting the device driver upstream to mainline? Here's the world's
> > tiniest violin playing, "my heart bleeds for you"....
>
> Deleting couple single liners is not a problem. Cleaning up 100KLoC
> patch for mainline *is* a problem.
>
> I know, I tried to do that work. Even getting it to staging quality
> was hard, and it was recently dropped due to security holes.
>
> Unfortunately google uses wakelocks as an excuse for not cleaning up
> stuff... "because readding those few lines would be too hard".
Actually, this isn't a good excuse any more as of 2.6.37-rc1. You can
basically replace wakelocks with wakeup sources and go ahead.
Thanks,
Rafael
> alternative, and is higher priority than any other consideration. If
> a product had 33% less battery lifetime, but was developed in
> mainline, would you buy that over a standard product? OK, maybe a
That's if you believe the Google thing that it can't be done any other
way. Which other vendors don't seem to be agree with.
> OTOH, if the original poster thinks that he can develop changes to the
> Android userspace that allow the use of an upstream kernel, and has
> just as good battery lifetime, and with a system which is just as
> debuggable and easy to maintain as the current android userspace, then
> by all means, I would love for him to try to prove that he can. And I
> will certainly be happy to introduce him to the Android developers who
> measure power usage in mobile devices using microwatt meters to see if
> he really can do as good of a job using a stock kernel.
Well actually there is a much better simple reason. One of the things you
get by using a standard kernel is the ability to dump a true Android
environment onto another device that's running something else as well.
I don't quite understand why people play some of the strange games they
do but being able to dump them on arbitary Linux platforms is no doubt
useful.
Alan
> Isn't the openwrt stuff just drivers and some arch specific code?
> Nothing that is core infrastructure, and nothing preventing them from
> submitting the drivers and arch code if they want to, right?
Actually openwrt has some core infrastructure for managing (ethernet)
switches as extra-fancy multiport PHYs. That means that all the drivers
in openwrt for the typical 5-8 port switches in home routers don't
really apply to mainline.
- R.
On Wed, 10 Nov 2010, Roland Dreier wrote:
> > Isn't the openwrt stuff just drivers and some arch specific code?
> > Nothing that is core infrastructure, and nothing preventing them from
> > submitting the drivers and arch code if they want to, right?
>
> Actually openwrt has some core infrastructure for managing (ethernet)
> switches as extra-fancy multiport PHYs. That means that all the drivers
> in openwrt for the typical 5-8 port switches in home routers don't
> really apply to mainline.
Why not? Those switches _ARE_ extra-fancy multiport PHYs. And AFAICT
we have no support for this stuff in mainline at all.
So where is the problem ?
Thanks,
tglx
On Wed, Nov 10, 2010 at 04:33:38PM -0800, Roland Dreier wrote:
> > Isn't the openwrt stuff just drivers and some arch specific code?
> > Nothing that is core infrastructure, and nothing preventing them from
> > submitting the drivers and arch code if they want to, right?
>
> Actually openwrt has some core infrastructure for managing (ethernet)
> switches as extra-fancy multiport PHYs. That means that all the drivers
> in openwrt for the typical 5-8 port switches in home routers don't
> really apply to mainline.
Why can't we merge that core infrastructure as well? Has it been
rejected for any specific reasons?
thanks,
greg k-h
Hello Roland,
Le Thursday 11 November 2010 01:33:38, Roland Dreier a ?crit :
> > Isn't the openwrt stuff just drivers and some arch specific code?
> > Nothing that is core infrastructure, and nothing preventing them from
> > submitting the drivers and arch code if they want to, right?
>
> Actually openwrt has some core infrastructure for managing (ethernet)
> switches as extra-fancy multiport PHYs. That means that all the drivers
> in openwrt for the typical 5-8 port switches in home routers don't
> really apply to mainline.
This is called "swconfig" in OpenWrt and it works in two parts:
- a swconfig driver, which interfaces the getting and setting of switches
attributes using netlink, therefore there is an user-space counter-part
- the switch drivers are implemented as phylib drivers with a phylib fixup
callback to allow proper detection of these (you cannot alwasy simply read the
standard PHY ID), the config_init callback will set correct defaults for the
switch to be usable even without swconfig
The rationale behind swconfig comes from the fact that the Marvell DSA switch
infrastructure is both too complex and too-specific to driver relatively
simpler switches.
One could therefore just use the "phylib switch driver" without swconfig and
have it working.
--
Florian
Le Thursday 11 November 2010 01:47:30, Greg KH a ?crit :
> On Wed, Nov 10, 2010 at 04:33:38PM -0800, Roland Dreier wrote:
> > > Isn't the openwrt stuff just drivers and some arch specific code?
> > > Nothing that is core infrastructure, and nothing preventing them from
> > > submitting the drivers and arch code if they want to, right?
> >
> > Actually openwrt has some core infrastructure for managing (ethernet)
> > switches as extra-fancy multiport PHYs. That means that all the drivers
> > in openwrt for the typical 5-8 port switches in home routers don't
> > really apply to mainline.
>
> Why can't we merge that core infrastructure as well? Has it been
> rejected for any specific reasons?
It has been not been submitted for review yet, I suppose we could do that
within the next couple days.
--
Florian
> > > Isn't the openwrt stuff just drivers and some arch specific code?
> > > Nothing that is core infrastructure, and nothing preventing them from
> > > submitting the drivers and arch code if they want to, right?
> >
> > Actually openwrt has some core infrastructure for managing (ethernet)
> > switches as extra-fancy multiport PHYs. That means that all the drivers
> > in openwrt for the typical 5-8 port switches in home routers don't
> > really apply to mainline.
>
> Why not? Those switches _ARE_ extra-fancy multiport PHYs. And AFAICT
> we have no support for this stuff in mainline at all.
>
> So where is the problem ?
There's no real problem. I was just pointing out that the openwrt
switch stuff actually does have some core infrastructure that mainline
is missing. ie openwrt is not just drivers and arch code.
But yes I agree mainline should really do a better job of supporting
ethernet switches, and clearly openwrt has the most real-world
experience with implementing that.
- R.
> Why can't we merge that core infrastructure as well? Has it been
> rejected for any specific reasons?
There's nothing obviously wrong with it, and I didn't mean to suggest
that there would be a problem merging it. I was just pointing out that
openwrt has done a bit more than just drivers and arch code.
- R.
On Friday 12 November 2010 04:15:56 Roland Dreier wrote:
> > > > Isn't the openwrt stuff just drivers and some arch specific code?
> > > > Nothing that is core infrastructure, and nothing preventing them
> > > > from submitting the drivers and arch code if they want to, right?
> > >
> > > Actually openwrt has some core infrastructure for managing (ethernet)
> > > switches as extra-fancy multiport PHYs. That means that all the
> > > drivers in openwrt for the typical 5-8 port switches in home routers
> > > don't really apply to mainline.
> >
> > Why not? Those switches _ARE_ extra-fancy multiport PHYs. And AFAICT
> > we have no support for this stuff in mainline at all.
> >
> > So where is the problem ?
>
> There's no real problem. I was just pointing out that the openwrt
> switch stuff actually does have some core infrastructure that mainline
> is missing. ie openwrt is not just drivers and arch code.
>
> But yes I agree mainline should really do a better job of supporting
> ethernet switches, and clearly openwrt has the most real-world
> experience with implementing that.
We are in the process of cleaning up that code and hope to submit for review
within the next few weeks.
--
Florian
Hi all,
On Sun, Nov 7, 2010 at 4:44 PM, Arnaud Lacombe <[email protected]> wrote:
> Hi,
>
> On Sun, Nov 7, 2010 at 10:57 AM, Greg KH <[email protected]> wrote:
>> [...]
>>
> Just a small comment to say that Android is not the only one (but
> certainly the most visible, and thus easiest to bash on) not making
> effort to get their stuff in mainline. OpenWRT people are also
> maintaining their fork of the kernel, without even using git, and not
> contributing much to mainline (I'm certainly mistaken on that last
> comment).
>
> I'm still stuck to use their 2.6.32 to use my AR71xx-based (MIPS)
> boards, just this part is +15kloc.
>
For the record, a first patch's set for AR71XX/AR724X/AR913X support
has been posted on linux-mips ml:
http://www.linux-mips.org/archives/linux-mips/2010-11/msg00085.html
- Arnaud