Re: [PATCH] abstract out bits of ldt.c

["Martin J. Bligh" <mbligh@mbligh.org>]

--Andrew Morton <akpm@osdl.org> wrote (on Sunday, August 07, 2005 17:41:29 -0700):

> "Martin J. Bligh" <mbligh@mbligh.org> wrote:
>> 
>> 
>> 
>> --Chris Wright <chrisw@osdl.org> wrote (on Sunday, August 07, 2005 16:44:11 -0700):
>> 
>> > * Martin J. Bligh (mbligh@mbligh.org) wrote:
>> >> Starting on the work to merge xen cleanly as a subarch.
>> >> Introduce make_pages_readonly and make_pages_writable where appropriate 
>> >> for Xen, defined as a no-op on other subarches. Same for 
>> > 
>> > Maybe this is a bad name, since make_pages_readonly/writable has
>> > intutitive meaning, and then is non-inutitively a no-op (for default).
>> 
>> You're welcome to suggest something else if you want, though it would
>> have been easier if you'd done it the first time you saw this patch,
>> not now. Going through this stuff multiple times is going to get very
>> boring very fast.
>> 
>> xen_make_pages_readonly / xen_make_pages_writable ?
>> 
> 
> Well we don't want to assume "xen" at this stage.  We're faced with a
> choice at present: to make the linux->hypervisor interface be some
> xen-specific and xen-controlled thing, or to make it a more formal and
> controlled kernel interface which talks to a generic hypervisor rather than
> assuming it's Xen down there.

Yes, more generic than xen would be better. I think mach-xen is probably
OK for now, but I agree we should avoid wedging xen_* in generic code
callouts. What I'm trying to do right now is rip the whole duplicated
files out of the xen patches.

> As long as it doesn't hamper performance or general code sanity, I think it
> would be better to make this a well-defined and controlled Linux interface.
> Some of the code to do that is starting to accumulate in -mm.  Everyone
> needs to sit down, take a look at the patches and the proposal and work out
> if this is the way to proceed.

We're faced with a difficult choice - the xen patches are hard to read
without refactoring them. On the other hand it's going to be very painful
to keep them in sync out of tree whilst doing the refactoring. I'd prefer
to merge up some bits as we go, though maybe I should keep those more
neutral than this. Sigh ... this is going to be extremely painful whatever
we do.

M.
-
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/