Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 20 Mar 2002 14:47:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 20 Mar 2002 14:47:46 -0500 Received: from garrincha.netbank.com.br ([200.203.199.88]:22788 "HELO netbank.com.br") by vger.kernel.org with SMTP id ; Wed, 20 Mar 2002 14:47:31 -0500 Date: Wed, 20 Mar 2002 16:36:48 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: "Martin J. Bligh" Cc: Andrea Arcangeli , Hugh Dickins , Dave McCracken , linux-kernel Subject: Re: Creating a per-task kernel space for kmap, user pagetables, et al In-Reply-To: <127930000.1016651345@flay> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Mar 2002, Martin J. Bligh wrote: > This, unfortunately, isn't a total solution - we may sometimes need to > modify the task's pagetables from outside the process context, eg. > swapout (thanks to dmc for pointing this out to me ;-)). For this, we'd > just use the existing kmap mechanism to create another mapping to use > temporarily, and we're no worse off than before. But on the whole I > think it wins us enough to be worthwhile. There is absolutely no problem mapping the page tables of another process into our own kmap space. It's just like what the kernel does now, except that it'll be scalable because each process has its own kmap array. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/