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
next prev parent 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