linux-kernel - Re: [PATCH 0/2] staging/android fixes

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]

Message-ID: <a55d774e0911290138j3d44a25aqce041f7a7a87d5a@mail.gmail.com>
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/