linux-kernel - Re: HTC Dream aka. t-mobile g1 support

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: <a55d774e0906121536m41715207td0cab3ba41d03bf2@mail.gmail.com>
Date:	Fri, 12 Jun 2009 15:36:08 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Ian Molton <ian@...menth.co.uk>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>,
	san@...roid.com, rlove@...gle.com, Greg KH <greg@...ah.com>
Subject: Re: HTC Dream aka. t-mobile g1 support

On Fri, Jun 12, 2009 at 3:31 PM, Pavel Machek<pavel@....cz> wrote:
>> > Is there a reason that this couldnt be done in userspace?
>>
>> It'd be a lot more overhead -- in some cases it's updated with
>> relatively fine granularity (wifi driver changing state, backlight
>> changing, etc), and on the kernel side it's just updating a shared
>> memory location with the current estimate.  Userspace doesn't
>> necessarily have the visibility into driver state to update it
>> accurately, and punching that information down to userspace and then
>> having userspace feed it back up to the kernel seems like more
>> overhead and code to maintain to me.
>
> Actually I agree with Brian here, this is better done at kernel level.
>
> OTOH, at least initially, it does not need to be done at all. It will
> make battery readings less reliable but hey... the battery meter does
> not work reliably anyway and estimating capacity left from voltage
> acceptably on other platforms...

I'd agree.  This stuff can wait until the core support is solid.  I'd
fight harder for conditional support for wakelocks since that has a
much bigger impact on battery life (being able to know when it's safe
to power collapse in idle, etc), whereas this just improves the
accuracy of the battery gauging.

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/