linux-kernel - Re: Attempted summary of suspend-blockers LKML thread, take two

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: <AANLkTikd6SvRH_u5hhEfqKRbYnwVpU0PN-NSUEtGyiA9@mail.gmail.com>
Date:	Mon, 9 Aug 2010 00:34:12 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Pavel Machek <pavel@....cz>
Cc:	david@...g.hm, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, florian@...kler.org,
	rjw@...k.pl, stern@...land.harvard.edu, peterz@...radead.org,
	tglx@...utronix.de, alan@...rguk.ukuu.org.uk, menage@...gle.com,
	david-b@...bell.net, James.Bottomley@...e.de, tytso@....edu,
	arjan@...radead.org, swmike@....pp.se, galibert@...ox.com,
	dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take two

On Mon, Aug 9, 2010 at 12:26 AM, Pavel Machek <pavel@....cz> wrote:
> Hi!
>
>> >I should have asked this earlier...  What exactly are the apps'
>> >compatibility constraints?  Source-level APIs?  Byte-code class-library
>> >invocations?  C/C++ dynamic linking?  C/C++ static linking (in other
>> >words, syscall)?
>>
>> For Java/Dalvik apps, the wakelock API is pertty high level -- it
>> talks to a service via RPC (Binder) that actually interacts with the
>> kernel.  Changing the basic kernel<->userspace interface (within
>
> Strange. Arve claimed that open/close is too slow, and few
> microseconds faster ioctl is needed, and now we learn it actually uses
> RPC.

For the high level Java API, yes.  For lower level userspace code,
like the code that processes keypresses, the kernel interface is used
directly.  I think an open/close per keypress would be a bit
excessive, for example.  In any case, that ignores the fact that it's
useful to have statistics, which are tricky to maintain meaningfully
if you destroy the handle after use every time (by closing the fd).

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/