[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1lkg4sk3f.fsf@ebiederm.dsl.xmission.com>
Date: Fri, 04 May 2007 09:07:48 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Andi Kleen <ak@...e.de>,
Chris Wright <chrisw@...s-sol.org>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Zachary Amsden <zach@...are.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "[PATCH] paravirt: Add startup infrastructure for paravirtualization"
Rusty Russell <rusty@...tcorp.com.au> writes:
> On Fri, 2007-05-04 at 08:13 -0600, Eric W. Biederman wrote:
>> We don't have any working code, there are no in tree users.
>
> Hi Eric,
>
> Lack of in-tree code is definitely not due to me. The code which uses
> it has been sitting in -mm for three months. Suddenly ripping this out
> and breaking all that work without replacing it is rude.
My memory is very fuzzy now, but I know it at least came up early on
that everyone should be using %esi to point to real mode data and
that didn't happen. None of the usual bootloader folks (myself
or HPA) appear to have been on the CC when this code was merged into
the kernel. Ignoring review comments, skipping the people who know
the code and the bootloader requirements and putting in code that is
so brittle no one can change it is another kind of rude.
I'm wondering how much of the paravirt code is getting in through
reviewer exhaustion?
The interface for bootloaders is as hard to change as the user space
syscall interface. I'm doing my best to nip this horror in the bud
now that I have looked into it enough to see what is going on.
The interface to bootloaders is quite different from the internal
kernel interfaces that we have all of the users captive so can change
it just by updating all of the users. Except when we are first adding
the interface anyway.
The only reason this is even changeable is that we don't have any
users, and the code is dead weight.
So since I didn't get the opportunity to NAK the code. I sent
a patch to revert once I understood it.
>> Therefore the code should go.
>
> Then put the patch is -mm, behind lguest. Or better, help me refine my
> patches and I'll happily do it for you.
Before lguest. Thank you very much. This code should never ever
have been in a stable kernel. It is a very ill conceived interface.
I have no problems helping you refine your patches, and am working
in that direction now.
I just think it is irresponsible to let something as potentially
problematic as this piece of code is to sit.
And frankly I don't think lguest should be merged until we are as
close to certain as human beings can get that have the ABI reviewed
and sorted out. ABIs unfortunately are very very hard to change.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists