[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1y7k4smmo.fsf@ebiederm.dsl.xmission.com>
Date: Fri, 04 May 2007 08:13:03 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: Andi Kleen <ak@...e.de>, Chris Wright <chrisw@...s-sol.org>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Zachary Amsden <zach@...are.com>,
Andrew Morton <akpm@...ux-foundation.org>,
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 05:56 -0600, Eric W. Biederman wrote:
>> This reverts commit c9ccf30d77f04064fe5436027ab9d2230c7cdd94.
>>
>> Entering the kernel at startup_32 without passing our real mode data
>> in %esi, and without guaranteeing that physical and virtual addresses
>> are identity mapped makes head.S impossible to maintain.
>
> Your assertion that these #ifdef-contained lines of code are "impossible
> to maintain" is theatrical. I'd prefer to wait until we actually have a
> replacement before we go ripping out working code.
It's not theatrical. It makes this code path extremely brittle and
very hard to change, which over the long term means that it is
impossible to maintain. Quickly resulting in a state where any little
change will break something. See Jeremy's impossible attempt to
detect if we start with physical addresses identity mapped or physical
address mapped at PAGE_OFFSET, just so he can clear the bss before we
test to see if we are running in para-virtualized environment.
The first step in making things better is removing this code (even in
your patches) so this patch doesn't get in the way.
We don't have any working code, there are no in tree users.
Therefore the code should go.
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