From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753805Ab3BAC2e (ORCPT ); Thu, 31 Jan 2013 21:28:34 -0500 Received: from relais.videotron.ca ([24.201.245.36]:11550 "EHLO relais.videotron.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752237Ab3BAC2c (ORCPT ); Thu, 31 Jan 2013 21:28:32 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Date: Thu, 31 Jan 2013 21:28:30 -0500 (EST) From: Nicolas Pitre To: "H. Peter Anvin" Cc: Russell King - ARM Linux , Michal Marek , hyojun.im@lge.com, raphael.andy.lee@gmail.com, linux-kbuild@vger.kernel.org, gunho.lee@lge.com, namhyung.kim@lge.com, x86@kernel.org, minchan.kim@lge.com, linux-kernel@vger.kernel.org, Josh Triplett , Nitin Gupta , Richard Purdie , Ingo Molnar , Joe Millenbach , chan.jeong@lge.com, Kyungsik Lee , Andrew Morton , Albin Tonnerre , CE Linux Developers List , Thomas Gleixner , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 0/4] Add support for LZ4-compressed kernels In-reply-to: <510AEDC2.80107@zytor.com> Message-id: References: <1359179447-31118-1-git-send-email-kyungsik.lee@lge.com> <20130128142510.68092e10.akpm@linux-foundation.org> <20130129101549.GP23505@n2100.arm.linux.org.uk> <51089523.3080804@zytor.com> <510AE6BF.4080303@zytor.com> <510AEDC2.80107@zytor.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 31 Jan 2013, H. Peter Anvin wrote: > On 01/31/2013 02:16 PM, Nicolas Pitre wrote: > >> > >> Some utterly weird things like the Xen domain builder do that, because > >> they have to. That is why we explicitly document that the payload is > >> ELF and how to access it in the bzImage spec. > > > > Are you kidding? > > > > And what format do they expect? > > > > I think they can be fairly flexible. Obviously gzip is always > supported. I don't know the details. > > > If people are doing weird things with formats we're about to remove then > > it's their fault if they didn't make upstream developers aware of it. > > And if the reason they didn't tell anyone is because it is too nasty for > > public confession then they simply deserve to be broken and come up with > > a more sustainable solution. > > Well, it is too nasty for public confession, but it's called > "paravirtualization". The fact that you are aware of it means we're not going to break them. But my point is that we must not be held back just in case someone out there might have painted himself in a corner without telling anyone. Nicolas