Hi,
Here is a patch to fix build for android specifics drivers.
What we should do next to prevent them from being removed in 2.6.23 ?
Is there any chance that all android stuff would be merged one day ?
Actually, we got a working 2.6.32 kernel for android here (with wakelock, ashm, etc..):
http://git.iksaif.net/?p=android-x86/kernel;a=shortlog;h=refs/heads/android-x86-backport
Thanks,
Corentin Chary (2):
staging/android: fix build issues
staging/android: remove BROKEN flag
drivers/staging/android/Kconfig | 1 -
drivers/staging/android/logger.c | 1 +
drivers/staging/android/lowmemorykiller.c | 6 ++++--
3 files changed, 5 insertions(+), 3 deletions(-)
Signed-off-by: Corentin Chary <[email protected]>
---
drivers/staging/android/logger.c | 1 +
drivers/staging/android/lowmemorykiller.c | 6 ++++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 6c10b45..64cc2a1 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -17,6 +17,7 @@
* GNU General Public License for more details.
*/
+#include <linux/sched.h>
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/miscdevice.h>
diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c
index 935d281..32314e8 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -100,15 +100,17 @@ static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
read_lock(&tasklist_lock);
for_each_process(p) {
struct mm_struct *mm;
+ struct signal_struct *sig;
int oom_adj;
task_lock(p);
mm = p->mm;
- if (!mm) {
+ sig = p->signal;
+ if (!mm || !sig) {
task_unlock(p);
continue;
}
- oom_adj = mm->oom_adj;
+ oom_adj = sig->oom_adj;
if (oom_adj < min_adj) {
task_unlock(p);
continue;
--
1.6.5.2
Signed-off-by: Corentin Chary <[email protected]>
---
drivers/staging/android/Kconfig | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index eb67563..2471949 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -2,7 +2,6 @@ menu "Android"
config ANDROID
bool "Android Drivers"
- depends on BROKEN
default N
---help---
Enable support for various drivers needed on the Android platform
--
1.6.5.2
On Sat, Nov 28, 2009 at 12:45 AM, Corentin Chary <[email protected]> wrote:
> Hi,
> Here is a patch to fix build for android specifics drivers.
>
> What we should do next to prevent them from being removed in 2.6.23 ?
>
> Is there any chance that all android stuff would be merged one day ?
> Actually, we got a working 2.6.32 kernel for android here (with wakelock, ashm, etc..):
> http://git.iksaif.net/?p=android-x86/kernel;a=shortlog;h=refs/heads/android-x86-backport
Arve's done a few revisions of the wakelock code with the linux-pm
list, and I know he's planning on trying to work through the remaining
issues (as I recall there was some discussion on read/write vs ioctl
interfaces to userspace) in the near future.
This really is the one piece that has the most impact on everything
else -- maintaining versions of the various platform hardware drivers
with and without wakelock support is messy.
I'm not sure if there are seriously issues with picking up ashmem or
logger. They are relatively small, simple, and self-contained. The
binder driver seemed to be much more contentious.
Brian
On Sat, Nov 28, 2009 at 09:45:13AM +0100, Corentin Chary wrote:
> Hi,
> Here is a patch to fix build for android specifics drivers.
>
> What we should do next to prevent them from being removed in 2.6.23 ?
Provide _real_ forward progress on the code. Google has not contributed
anything, and neither has anyone else, becides various tiny fixups, like
the low-memory one that you just did.
> Is there any chance that all android stuff would be merged one day ?
That is up to the developers of the code. I would hope that it would,
but it needs a _lot_ of work to get there.
So for now, unless you are willing to maintain this code and work to get
it merged into the main kernel tree (which will require changes to the
kernel/userspace apis in a number of places, which will require buy-in
by the owners of that userspace code), I'm going to have to drop the
code.
sorry,
greg k-h
Hi!
> > Here is a patch to fix build for android specifics drivers.
> >
> > What we should do next to prevent them from being removed in 2.6.23 ?
> >
> > Is there any chance that all android stuff would be merged one day ?
> > Actually, we got a working 2.6.32 kernel for android here (with wakelock, ashm, etc..):
> > http://git.iksaif.net/?p=android-x86/kernel;a=shortlog;h=refs/heads/android-x86-backport
>
> Arve's done a few revisions of the wakelock code with the linux-pm
> list, and I know he's planning on trying to work through the remaining
> issues (as I recall there was some discussion on read/write vs ioctl
> interfaces to userspace) in the near future.
>
> This really is the one piece that has the most impact on everything
> else -- maintaining versions of the various platform hardware drivers
> with and without wakelock support is messy.
It is really not that bad. Yes, it touches most drivers, but it is few
lines per driver and easy to remove.
Waiting for wakelocks (1year plus, AFAICT) before merging hw drivers
seems like very slow way forward.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, Nov 29, 2009 at 12:43 AM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>> > Here is a patch to fix build for android specifics drivers.
>> >
>> > What we should do next to prevent them from being removed in 2.6.23 ?
>> >
>> > Is there any chance that all android stuff would be merged one day ?
>> > Actually, we got a working 2.6.32 kernel for android here (with wakelock, ashm, etc..):
>> > http://git.iksaif.net/?p=android-x86/kernel;a=shortlog;h=refs/heads/android-x86-backport
>>
>> Arve's done a few revisions of the wakelock code with the linux-pm
>> list, and I know he's planning on trying to work through the remaining
>> issues (as I recall there was some discussion on read/write vs ioctl
>> interfaces to userspace) in the near future.
>>
>> This really is the one piece that has the most impact on everything
>> else -- maintaining versions of the various platform hardware drivers
>> with and without wakelock support is messy.
>
> It is really not that bad. Yes, it touches most drivers, but it is few
> lines per driver and easy to remove.
>
> Waiting for wakelocks (1year plus, AFAICT) before merging hw drivers
> seems like very slow way forward.
I'm not suggesting we hold off on everything until they're in, just
saying it'll simplify things once they are.
I'd like to get to a point where we can ship out of the upstream
kernel and that's going to need power management to work. If we can
sort out wakelocks (as it seemed like we were getting close to),
that's one less difference to maintain.
Brian
> >> Arve's done a few revisions of the wakelock code with the linux-pm
> >> list, and I know he's planning on trying to work through the remaining
> >> issues (as I recall there was some discussion on read/write vs ioctl
> >> interfaces to userspace) in the near future.
> >>
> >> This really is the one piece that has the most impact on everything
> >> else -- maintaining versions of the various platform hardware drivers
> >> with and without wakelock support is messy.
> >
> > It is really not that bad. Yes, it touches most drivers, but it is few
> > lines per driver and easy to remove.
> >
> > Waiting for wakelocks (1year plus, AFAICT) before merging hw drivers
> > seems like very slow way forward.
>
> I'm not suggesting we hold off on everything until they're in, just
> saying it'll simplify things once they are.
That's certainly true :-).
> I'd like to get to a point where we can ship out of the upstream
> kernel and that's going to need power management to work. If we can
> sort out wakelocks (as it seemed like we were getting close to),
> that's one less difference to maintain.
Yes, that would be nice.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html