public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alain Knaff <alain@knaff.lu>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [update5] [PATCH] init: bzip2 or lzma -compressed kernels and initrds
Date: Sat, 11 Oct 2008 09:28:28 +0200	[thread overview]
Message-ID: <48F0559C.1040705@knaff.lu> (raw)
In-Reply-To: <48EFC9A0.5070907@zytor.com>

H. Peter Anvin wrote:
> Alain Knaff wrote:
>> H. Peter Anvin wrote:
>>> Hi Alain,
>>>
>>> Are you planning to submit an updated patch any time soon?  If so,
>>> please separate the ARM, x86, library and generic portions into separate
>>> patches.  It looks like at least some of them already went into ARM,
>>> which makes it impractical to include this as a monolithic patch, which
>>> it really shouldn't have to be, anyway.
>>>
>>>     -hpa
>>
>> I'll look into it (the split) this weekend, if I'll find the time.
>> Should each part be compilable on its own? If so, it might be difficult
>> to do the split along the lines outlined above.
>>
> 
> Not individually, but part 1 should compile, as should parts 1+2, etc.
> 
> This pretty much means the order should be:
> 
> 1. add library functions
> 2. generic functionality
> 3. x86 functionality
> 4. ARM functionality

Unfortunately, due to the nature of the patch, it will be hard to
separate out "x86 functionality" from changes in lib/inflate.c . Indeed,
a large part of the patch consists in moving some gzip-specific headers
and internal variable declarations from the callers:
arch/x86/boot/compressed/misc.c on one hand, and init/do_mounts_rd.c and
init/initramfs.c on the other hand into lib/inflate.c

So, leaving out the x86-specific change
(arch/x86/boot/compressed/misc.c) in the first change, would force to
leave that change out of lib/inflate.c as well (or else, the
above-listed items would be doubly defined). But, if I left out these
changes of lib/inflate.c, I'd need to leave them out of and
init/do_mounts_rd.c and init/initramfs.c too (or else the above-listed
items would not be defined at all in that situation). Can you suggest a
solution? I could theoretically break that dependency chain using an
#ifdef (as was the case until patch 3), but apparently #ifdef's are
highly frowned upon. Or was it just the name of the ifdef ("NEW_CODE")
that you objected to? Another option would be to (temporarily) keep 2
copies of lib/inflate.c around, but somehow that doesn't feel right.

So can you suggest some way out of the situation?

> 
> Soem of these may be obsolete; I noticed collisions with the ARM tree.
> 
>     -hpa

Great! Could you tell me where to download the ARM tree from, so that I
can have a look?

Thanks,

Alain


  reply	other threads:[~2008-10-11  7:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-09  6:41 [update3] [PATCH] init: bzip2 or lzma -compressed kernels and initrds Alain Knaff
2008-09-11 22:43 ` H. Peter Anvin
2008-09-11 23:16   ` Alain Knaff
2008-09-11 23:21     ` H. Peter Anvin
2008-09-22  6:16       ` [update5] " Alain Knaff
2008-09-22 16:08         ` H. Peter Anvin
2008-09-22 16:15           ` Alain Knaff
2008-09-23 19:07             ` H. Peter Anvin
2008-09-23 19:44               ` Alain Knaff
2008-09-23 20:07                 ` H. Peter Anvin
2008-09-23 21:07                 ` H. Peter Anvin
2008-09-23 21:25                   ` Alain Knaff
2008-09-23 21:30                     ` H. Peter Anvin
2008-09-23 21:49                       ` H. Peter Anvin
2008-09-23 22:00                       ` Alain Knaff
2008-09-23 22:19                         ` H. Peter Anvin
2008-09-23 22:23                           ` Alain Knaff
2008-10-09 17:44                             ` H. Peter Anvin
2008-10-10  3:11                               ` Alain Knaff
2008-10-10 21:31                                 ` H. Peter Anvin
2008-10-11  7:28                                   ` Alain Knaff [this message]
2008-10-11 14:10                                     ` H. Peter Anvin
2008-10-13  7:02                                     ` Alain Knaff
2008-09-23 21:37                     ` H. Peter Anvin
2008-09-24  3:52                     ` Willy Tarreau
  -- strict thread matches above, loose matches on Subject: below --
2008-09-11 23:54 Alain Knaff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48F0559C.1040705@knaff.lu \
    --to=alain@knaff.lu \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox