From: "H. Peter Anvin" <hpa@zytor.com>
To: Alain Knaff <alain@knaff.lu>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>
Subject: The bzip2/lzma patches
Date: Tue, 30 Dec 2008 18:47:34 -0800 [thread overview]
Message-ID: <495ADD46.7080601@zytor.com> (raw)
Hi Alain,
I finally got the tree with your latest bzip2/LZMA code unburied. My
apologies for having sat on it for so long (you know why.)
Anyway, I did run into a few things that I'd really like to get fixed.
First of all, there are more than just the x86 and ARM tree which is
using the old API, I count at least four more architectures. I can't
apply the ARM tree anyway, and we clearly need a saner migration way.
Second, the ugly if...goto hacks in init/initramfs.c could be much
cleaner handled by iterating down a list of function pointers -- except
that gunzip() seems to have a different return value (in init/than the
others?!
Third, you're using the construct if (!foo() < 0 && message == NULL)
... which is wrong on three(!) accounts, one technical (! has higher
precedence than <) and two stylistic (write >= instead of !(.. < ..) and
write !message instead of message == NULL).
I think the solution to all of this is to introduce a new function
instead of gunzip(), and have the old gunzip() be a wrapper using the
old ABI. That is much cleaner than relying on #ifdef NEW_CODE.
Finally, I know I suggested it, but I don't think the
<linux/decompress/*.h> header file are justified given that they only
contain a single function header. Might as well put them all in a
single <linux/decompress.h> header.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next reply other threads:[~2008-12-31 2:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-31 2:47 H. Peter Anvin [this message]
2008-12-31 8:47 ` The bzip2/lzma patches Alain Knaff
2008-12-31 13:42 ` Sam Ravnborg
2008-12-31 14:22 ` 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=495ADD46.7080601@zytor.com \
--to=hpa@zytor.com \
--cc=alain@knaff.lu \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.