[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100607080357.GB15851@infradead.org>
Date: Mon, 7 Jun 2010 04:03:57 -0400
From: Christoph Hellwig <hch@...radead.org>
To: Brian Swetland <swetland@...gle.com>
Cc: Christoph Hellwig <hch@...radead.org>,
James Bottomley <James.Bottomley@...e.de>,
Thomas Gleixner <tglx@...utronix.de>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Florian Mickler <florian@...kler.org>,
Vitaly Wool <vitalywool@...il.com>,
Arve Hj?nnev?g <arve@...roid.com>,
Arjan van de Ven <arjan@...radead.org>, tytso@....edu,
Peter Zijlstra <peterz@...radead.org>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>, Neil Brown <neilb@...e.de>,
Linux PM <linux-pm@...ts.linux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Felipe Balbi <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] suspend blockers & Android integration
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
> Somebody will have to broker a deal with the frameworks/apps folks to
> get rid of the binder. They like it a lot. Of course if somebody
> built a drop-in replacement for the userspace side that didn't require
> a kernel driver, had the same performance characteristics, solved the
> same problems, etc, they could probably make an argument for it (or
> just provide it as a drop-in replacement for people who want a more
> "pure" linux underneath Android, even if we didn't pick it up).
This wasn't really directed at you, but rather about people talking
about running a mainline kernel on Android in this thread. As I said
this is a lot more work then sorting out the drivers - with or without
suspend blockers.
> The group ID stuff works incredibly well for gating device access --
> we ensure that devices that need access from various processes end up
> with perms like 0660 root audio (say for a raw audio interface), and
> then we assure that processes which have the "may use audio hardware"
> permission are executed with audio as an additional group. We ended
> up using the same model to control socket, raw socket, and bt socket
> access because at the time we could not find a reasonable way to grant
> or exclude such permissions on a process by process basis.
> Maintaining about 20-30 lines of diffs to make that work was not a bad
> tradeoff (and we don't expect those patches to go upstream). If
> there's a way to accomplish this without patching the kernel, we're
> all ears.
I'd have to take a look again on how this is implemented in details.
If it's just overriding the capabilities it's really hard to do in
the current model as the capabilities aren't fine grained enough
currently, even with the existing per-file and per-process capabilities.
If it's mostly overriding regular unix file permissions it's easily
doable with ACLs, or in fact just with group ownership at the filesystem
level, without kernel hacks.
--
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