From: Alan Cox <alan@redhat.com>
Message-Id: <200208021748.g72HmnV08218@devserv.devel.redhat.com>
Subject: Re: Accelerating user mode linux
To: jdike@karaya.com (Jeff Dike)
Date: Fri, 2 Aug 2002 13:48:49 -0400 (EDT)
Cc: alan@redhat.com (Alan Cox), linux-kernel@vger.kernel.org
In-Reply-To: <200208021828.NAA02466@ccure.karaya.com> from "Jeff Dike" at Aug 02, 2002 01:28:18 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1156
Lines: 27

> So, there's nothing special about entering userspace for the first time.
> Everything is under a signal frame, so any time something needs to enter
> userspace, it just returns through it.

Ok

> This has the slight disadvantage that the process address space isn't directly
> accessible, but I can live with that.  A virt_to_phys translation isn't too
> painful.

Right

> This raises the question of how the process address spaces are created.  For
> a variety of reasons unrelated to altmm (which I can go into if anyone's
> interested), I want address spaces to be separate user-visible objects.  

That really makes all the existing code not work with it. Doing an altmm
is easy in the sense that it doesn't require 20 new syscall and doesnt
slow down the main kernel paths for a single odd case.

I can see why there is a need to manipulate the other mm I need to think
about the right way to handle it.
-
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/