linux-kernel - Re: [PATCH] Revert "[PATCH] paravirt: Add startup infrastructure for paravirtualization"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m17irosjif.fsf@ebiederm.dsl.xmission.com>
Date:	Fri, 04 May 2007 09:20:24 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Chris Wright <chrisw@...s-sol.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"

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> Eric W. Biederman wrote:
>> 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.
>
> Removing the code now is premature.  I'm presuming you're proposing this
> as a .23 change, since we're planning on changing the paravirt boot to
> make use of bzImage and the boot protocol then anyway.

.22 and possibly -stable.  -stable doesn't really matter because it is dead
code.

> The world isn't going to fall apart if its in there for a couple of months.

As long as the code remains dead and unused I don't really care when we purge it.

             That code should NEVER EVER be used.

               That code is UNMAINTAINABLE.

The code encourages random ABIs so we don't even know what we are supporting.
Once used in a production environment (i.e. where we have to support it)
it makes further changes to head.S essentially impossible.

Despite the lack of Documentation we not counting the paravirt mess in
head.S we have a well defined ABI for starting a linux-kernel.  Given the
generally difficulty of changing bootloaders I have no interesting is
messing up a good thing.

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/