On Tue, Oct 27, 2009 at 12:40:07PM +0800, Eric Miao wrote:
> > Compiling broke since commit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184> > headers: remove sched.h from poll.h> >> > Adding <linux/sched.h> to fix this compiling bug.
I have now just marked the android drivers as broken, as this is not the
only build error in them at the moment :(
thanks,
greg k-h

Greg KH wrote:
> On Tue, Oct 27, 2009 at 12:40:07PM +0800, Eric Miao wrote:>>> Compiling broke since commit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184>>> headers: remove sched.h from poll.h>>>>>> Adding <linux/sched.h> to fix this compiling bug.> > I have now just marked the android drivers as broken, as this is not the> only build error in them at the moment :(>
Yeah, actually the drivers/staging/android/lowmemorykiller.c has been failing to compile for a long
time, because that struct mm_struct does not have a field named oom_adj. All the Android drivers are
compiled as modules in Ubuntu kernel package, except this one.
Although Android public kernel is still in 2.6.29, it's own driver is totally different with our
mainline staging version. Is there any plan to sync with it?
Thanks,
-Bryan

On Thu, Oct 29, 2009 at 09:01:07AM +0800, Bryan Wu wrote:
> Greg KH wrote:> > On Tue, Oct 27, 2009 at 12:40:07PM +0800, Eric Miao wrote:> >>> Compiling broke since commit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184> >>> headers: remove sched.h from poll.h> >>>> >>> Adding <linux/sched.h> to fix this compiling bug.> > > > I have now just marked the android drivers as broken, as this is not the> > only build error in them at the moment :(> > > > Yeah, actually the drivers/staging/android/lowmemorykiller.c has been> failing to compile for a long time, because that struct mm_struct does> not have a field named oom_adj. All the Android drivers are compiled> as modules in Ubuntu kernel package, except this one.> > Although Android public kernel is still in 2.6.29, it's own driver is> totally different with our mainline staging version. Is there any plan> to sync with it?
No, Google has abandoned any current effort to push code upstream for
the past year :(
The android drivers are deleted in linux-next and will go away in 2.6.33
because of this.
thanks,
greg k-h

Greg KH wrote:
> On Thu, Oct 29, 2009 at 09:01:07AM +0800, Bryan Wu wrote:>> Greg KH wrote:>>> On Tue, Oct 27, 2009 at 12:40:07PM +0800, Eric Miao wrote:>>>>> Compiling broke since commit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184>>>>> headers: remove sched.h from poll.h>>>>>>>>>> Adding <linux/sched.h> to fix this compiling bug.>>> I have now just marked the android drivers as broken, as this is not the>>> only build error in them at the moment :(>>>>> Yeah, actually the drivers/staging/android/lowmemorykiller.c has been>> failing to compile for a long time, because that struct mm_struct does>> not have a field named oom_adj. All the Android drivers are compiled>> as modules in Ubuntu kernel package, except this one.>>>> Although Android public kernel is still in 2.6.29, it's own driver is>> totally different with our mainline staging version. Is there any plan>> to sync with it?> > No, Google has abandoned any current effort to push code upstream for> the past year :(> > The android drivers are deleted in linux-next and will go away in 2.6.33> because of this.>
Thanks a lot for this update. It looks like we need to consider to drop Android
modules in our Ubuntu kernel building somehow.
Cheers,
-Bryan

On Thu, Oct 29, 2009 at 09:11:39AM +0800, Bryan Wu wrote:
> Greg KH wrote:> > On Thu, Oct 29, 2009 at 09:01:07AM +0800, Bryan Wu wrote:> >> Greg KH wrote:> >>> On Tue, Oct 27, 2009 at 12:40:07PM +0800, Eric Miao wrote:> >>>>> Compiling broke since commit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184> >>>>> headers: remove sched.h from poll.h> >>>>>> >>>>> Adding <linux/sched.h> to fix this compiling bug.> >>> I have now just marked the android drivers as broken, as this is not the> >>> only build error in them at the moment :(> >>>> >> Yeah, actually the drivers/staging/android/lowmemorykiller.c has been> >> failing to compile for a long time, because that struct mm_struct does> >> not have a field named oom_adj. All the Android drivers are compiled> >> as modules in Ubuntu kernel package, except this one.> >>> >> Although Android public kernel is still in 2.6.29, it's own driver is> >> totally different with our mainline staging version. Is there any plan> >> to sync with it?> > > > No, Google has abandoned any current effort to push code upstream for> > the past year :(> > > > The android drivers are deleted in linux-next and will go away in 2.6.33> > because of this.> > > > Thanks a lot for this update. It looks like we need to consider to drop Android > modules in our Ubuntu kernel building somehow.
As no one is using them, it should be trivial to just change your kernel
config, right?
thanks,
greg k-h

Greg KH wrote:
> On Thu, Oct 29, 2009 at 09:11:39AM +0800, Bryan Wu wrote:>> Greg KH wrote:>>> On Thu, Oct 29, 2009 at 09:01:07AM +0800, Bryan Wu wrote:>>>> Greg KH wrote:>>>>> On Tue, Oct 27, 2009 at 12:40:07PM +0800, Eric Miao wrote:>>>>>>> Compiling broke since commit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184>>>>>>> headers: remove sched.h from poll.h>>>>>>>>>>>>>> Adding <linux/sched.h> to fix this compiling bug.>>>>> I have now just marked the android drivers as broken, as this is not the>>>>> only build error in them at the moment :(>>>>>>>>> Yeah, actually the drivers/staging/android/lowmemorykiller.c has been>>>> failing to compile for a long time, because that struct mm_struct does>>>> not have a field named oom_adj. All the Android drivers are compiled>>>> as modules in Ubuntu kernel package, except this one.>>>>>>>> Although Android public kernel is still in 2.6.29, it's own driver is>>>> totally different with our mainline staging version. Is there any plan>>>> to sync with it?>>> No, Google has abandoned any current effort to push code upstream for>>> the past year :(>>>>>> The android drivers are deleted in linux-next and will go away in 2.6.33>>> because of this.>>>>> Thanks a lot for this update. It looks like we need to consider to drop Android >> modules in our Ubuntu kernel building somehow.> > As no one is using them, it should be trivial to just change your kernel> config, right?>
The reason we include them is that we wanna port the Android runtime environment
to Ubuntu. Then the Android applications can run on Android compatible Ubuntu OS
directly without any modification.
The Android runtime environment needs some Android drivers such as Binder.
But now, it is hard for us to do that without a workable Android drivers in
mainline.
Thanks
-Bryan

On Thu, Oct 29, 2009 at 09:27:40AM +0800, Bryan Wu wrote:
> Greg KH wrote:> > On Thu, Oct 29, 2009 at 09:11:39AM +0800, Bryan Wu wrote:> >> Greg KH wrote:> >>> On Thu, Oct 29, 2009 at 09:01:07AM +0800, Bryan Wu wrote:> >>>> Greg KH wrote:> >>>>> On Tue, Oct 27, 2009 at 12:40:07PM +0800, Eric Miao wrote:> >>>>>>> Compiling broke since commit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184> >>>>>>> headers: remove sched.h from poll.h> >>>>>>>> >>>>>>> Adding <linux/sched.h> to fix this compiling bug.> >>>>> I have now just marked the android drivers as broken, as this is not the> >>>>> only build error in them at the moment :(> >>>>>> >>>> Yeah, actually the drivers/staging/android/lowmemorykiller.c has been> >>>> failing to compile for a long time, because that struct mm_struct does> >>>> not have a field named oom_adj. All the Android drivers are compiled> >>>> as modules in Ubuntu kernel package, except this one.> >>>>> >>>> Although Android public kernel is still in 2.6.29, it's own driver is> >>>> totally different with our mainline staging version. Is there any plan> >>>> to sync with it?> >>> No, Google has abandoned any current effort to push code upstream for> >>> the past year :(> >>>> >>> The android drivers are deleted in linux-next and will go away in 2.6.33> >>> because of this.> >>>> >> Thanks a lot for this update. It looks like we need to consider to drop Android > >> modules in our Ubuntu kernel building somehow.> > > > As no one is using them, it should be trivial to just change your kernel> > config, right?> > > > The reason we include them is that we wanna port the Android runtime environment > to Ubuntu. Then the Android applications can run on Android compatible Ubuntu OS > directly without any modification.> > The Android runtime environment needs some Android drivers such as Binder.
Don't you also need the wakelocks and the hooks in the core of the
kernel to tie into the binder mess?
> But now, it is hard for us to do that without a workable Android drivers in > mainline.
Then push on Google to get them cleaned up and fixed! Or do it
yourself, all I need is a developer to take ownership of the code.
thanks,
greg k-h

Greg KH wrote:
> On Thu, Oct 29, 2009 at 09:27:40AM +0800, Bryan Wu wrote:>> Greg KH wrote:>>> On Thu, Oct 29, 2009 at 09:11:39AM +0800, Bryan Wu wrote:>>>> Greg KH wrote:>>>>> On Thu, Oct 29, 2009 at 09:01:07AM +0800, Bryan Wu wrote:>>>>>> Greg KH wrote:>>>>>>> On Tue, Oct 27, 2009 at 12:40:07PM +0800, Eric Miao wrote:>>>>>>>>> Compiling broke since commit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184>>>>>>>>> headers: remove sched.h from poll.h>>>>>>>>>>>>>>>>>> Adding <linux/sched.h> to fix this compiling bug.>>>>>>> I have now just marked the android drivers as broken, as this is not the>>>>>>> only build error in them at the moment :(>>>>>>>>>>>>> Yeah, actually the drivers/staging/android/lowmemorykiller.c has been>>>>>> failing to compile for a long time, because that struct mm_struct does>>>>>> not have a field named oom_adj. All the Android drivers are compiled>>>>>> as modules in Ubuntu kernel package, except this one.>>>>>>>>>>>> Although Android public kernel is still in 2.6.29, it's own driver is>>>>>> totally different with our mainline staging version. Is there any plan>>>>>> to sync with it?>>>>> No, Google has abandoned any current effort to push code upstream for>>>>> the past year :(>>>>>>>>>> The android drivers are deleted in linux-next and will go away in 2.6.33>>>>> because of this.>>>>>>>>> Thanks a lot for this update. It looks like we need to consider to drop Android >>>> modules in our Ubuntu kernel building somehow.>>> As no one is using them, it should be trivial to just change your kernel>>> config, right?>>>>> The reason we include them is that we wanna port the Android runtime environment >> to Ubuntu. Then the Android applications can run on Android compatible Ubuntu OS >> directly without any modification.>>>> The Android runtime environment needs some Android drivers such as Binder.> > Don't you also need the wakelocks and the hooks in the core of the> kernel to tie into the binder mess?>
Yeah, that is complicated. -:(
>> But now, it is hard for us to do that without a workable Android drivers in >> mainline.> > Then push on Google to get them cleaned up and fixed! Or do it> yourself, all I need is a developer to take ownership of the code.>
I'm doing a task which is trying to merge Android patches to Ubuntu kernel and
mainline, not only the Android drivers but also the ARM port code which is not
in mainline.
But since Android kernel is 2.6.29 and ours or mainline is 2.6.31+, you know it
needs much more effort without Google's help.
And for sure, I'm very happy to help this out.
Cheers,
-Bryan

On Wed, Oct 28, 2009 at 6:55 PM, Bryan Wu <bryan.wu@canonical.com> wrote:
>>> But now, it is hard for us to do that without a workable Android drivers>>> in mainline.>>>> Then push on Google to get them cleaned up and fixed! Or do it>> yourself, all I need is a developer to take ownership of the code.>> I'm doing a task which is trying to merge Android patches to Ubuntu kernel> and mainline, not only the Android drivers but also the ARM port code which> is not in mainline.>> But since Android kernel is 2.6.29 and ours or mainline is 2.6.31+, you know> it needs much more effort without Google's help.>> And for sure, I'm very happy to help this out.
We (Google) definitely want to get back in sync with mainline (as I've
mentioned earlier in this or a related thread), and we're planning on
snapping up our kernel trees to 2.6.32+ once we get past various
deadlines in the near future. Obviously action speaks louder than
words here, and I understand Greg's frustration at the slow pace so
far and appreciate his efforts to encourage us to stop dropping the
ball.
Probably the two biggest pain points for general driver support are
wakelocks (which we were making some progress on getting cleaned up on
the linux-pm list -- Arve will be respinning those patchsets for
review again before long) and some of the gpio support. Otherwise,
most of the drivers don't have a lot of dependencies on new core
kernel infrastructure and many effectively stand alone. For some of
the qualcomm chipsets, there is a fair bit of layering needed for
functions owned by the modem or dsp cores -- smem / smd / rpc / etc.
Brian

Hi!
>>> But now, it is hard for us to do that without a workable Android >>> drivers in mainline.>>>> Then push on Google to get them cleaned up and fixed! Or do it>> yourself, all I need is a developer to take ownership of the code.>>>> I'm doing a task which is trying to merge Android patches to Ubuntu > kernel and mainline, not only the Android drivers but also the ARM port > code which is not in mainline.>> But since Android kernel is 2.6.29 and ours or mainline is 2.6.31+, you > know it needs much more effort without Google's help.>> And for sure, I'm very happy to help this out.
I guess Greg will be happy to put android stuff back into staging if
you promise to maintain it. That should be fairly low effort (hour per
week?). Basically you have to respond to email, fix it when it breaks,
and perhaps test compile it when -rc1 comes...
Sounds easy enough, no?
Pavel

Pavel Machek wrote:
> Hi!> >>>> But now, it is hard for us to do that without a workable Android >>>> drivers in mainline.>>> Then push on Google to get them cleaned up and fixed! Or do it>>> yourself, all I need is a developer to take ownership of the code.>>>>> I'm doing a task which is trying to merge Android patches to Ubuntu >> kernel and mainline, not only the Android drivers but also the ARM port >> code which is not in mainline.>>>> But since Android kernel is 2.6.29 and ours or mainline is 2.6.31+, you >> know it needs much more effort without Google's help.>>>> And for sure, I'm very happy to help this out.> > I guess Greg will be happy to put android stuff back into staging if> you promise to maintain it. That should be fairly low effort (hour per> week?). Basically you have to respond to email, fix it when it breaks,> and perhaps test compile it when -rc1 comes...> > Sounds easy enough, no?> Pavel
Great, I do love to maintain it with the help from Brian Swetland and other
Google folks.
Thanks a lot, Greg and Pavel.
-Bryan