Re: [PATCH v2 01/16] FS: Added demand paging markers to filesystem
On Wed, May 09, 2012 at 01:59:40PM +, Arnd Bergmann wrote: > My feeling is that we should just treat every (REQ_SYNC | REQ_READ) > request the same and let them interrupt long-running writes, > independent of whether it's REQ_META or demand paging. It's funny that the CFQ scheduler used to boost metadata reads that have REQ_META set - in fact it still does for those filesystems using the now split out REQ_PRIO. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers & Android integration
On Mon, Jun 07, 2010 at 12:26:55AM +0200, Thomas Gleixner wrote: > That takes a lot of the bullshit arguments about downstream users > being hurt out of the discussion. The above problems are way more > complex to resolve than the suspend blocker details. > > That's another prove why we can let the drivers flow in (in the worst > case w/o the suspend blocker stubs) and have no pressure to resolve > the suspend blocker problem yesterday. > > That said, after thinking more about it, I'm advocating the stubs > solution with a clear removal / decision date constraint > (e.g. 2.6.37), as it forces all involved parties to stay tuned and not > to forget about it. I'm curious about the outcome :) As long as we have that clear removal schedule I'm fine with in-kernel suspend blocker stubs. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers & Android integration
On Sun, Jun 06, 2010 at 12:15:10PM -0700, Brian Swetland wrote: > I was shocked when Greg pulled the binder driver and some of the other > "generic" android drivers into staging, because it was always my > assumption that nobody upstream would want them. We did get some > bugfixes for the binder driver (thanks!) but the general reaction was > pretty much the same as yours here. I then was relatively unsurprised > when it was dropped (we find it useful, upstream finds it useless, not > much else to say). > > The various SoC peripheral drivers are, I suspect, much less > contentious (modulo suspend blocker usage and any necessary kernel > style cleanup). Yes. That's what makes me wonder about some parts of the discussion here. Getting the drivers for one or more of the android plattforms in is not a problem. I'd say it could have easily been done with the manweeks spent arguing in this and related threads. The much bigger issues is to get android userspace running on a more or less vanilla kernel, that is withoutthe binder, without the rather interesting group ID based security hack^H^H^H^Hmodel, without the suspend blocker userspace API and so on, and so on. So for people who really care about running a mainline kernel on their android device doing that part first on a generic ARM board in qemu might be much better first step work. On the other hand I've heard that various hardware vendors or parties closed to them are rather annoyed by their drivers beeing stuck in the android tree - but that can be easily solved by getting removing the suspend blockers (at least temporarily), cleaning up a few bits here and there and getting them in. It's not rocket science to get support for ARM SOC number 1654 into the mainline kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers & Android integration
On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote: > Well, we sort of tried this when Greg pulled some of them into the > staging tree. The problem is that without the annotations, the drivers > are still different, and patches won't apply, so, unsurprisingly, they > didn't get improved or even maintained. Err, the biggest pile in staging was meta drivers like the binder or some oom killer magic which are flat out braindead and wrong and have no chance going into mainline anyway. That's something different from real hardware drivers, although a few of those made it into staging as well if I remember correctly. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
