lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 29 Nov 2009 01:38:50 -0800
From:	Brian Swetland <swetland@...gle.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Corentin Chary <corentincj@...aif.net>,
	"Arve Hj??nnev??g" <arve@...gle.com>,
	Greg Kroah-Hartman <greg@...ah.com>,
	Chih-Wei Huang <cwhuang@...ux.org.tw>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] staging/android fixes

On Sun, Nov 29, 2009 at 12:43 AM, Pavel Machek <pavel@....cz> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists