On Sat, 16 Feb 2008 11:41:35 +0100 Brice Goglin <Brice.Goglin@inria.fr> wrote:"looks good" maybe. But it's in the details where I fear this will come unstuck. The likelihood that some callbacks really will want to be able to block in places where this interface doesn't permit that - either to wait for IO to complete or to wait for other threads to clear critical regions. From that POV it doesn't look like a sufficiently general and useful design. Looks like it was grafted onto the current VM implementation in a way which just about suits two particular clients if they try hard enough. Which is all perfectly understandable - it would be hard to rework core MM to be able to make this interface more general. But I do think it's half-baked and there is a decent risk that future (or present) code which _could_ use something like this won't be able to use this one, and will continue to futz with mlock, page-pinning, etc. Not that I know what the fix to that is.. --
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Eric Paris | [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning |
| holzheu | Re: [RFC/PATCH] Documentation of kernel messages |
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Alan Cox | Re: [BUG] New Kernel Bugs |
