From: "H. Peter Anvin" <hpa@zytor.com>
To: Milton Miller <miltonm@bga.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [klibc 00/43] klibc as a historyless patchset
Date: Tue, 27 Jun 2006 12:12:53 -0700 [thread overview]
Message-ID: <44A18335.7020706@zytor.com> (raw)
In-Reply-To: <29ea762c2af4a4dc3168b6bd980bbf67@bga.com>
Milton Miller wrote:
> As a historyless patchset, this gets the merge all wrong.
>
> If the reason to put this in tree is to keep the kernel just working
> then there is a great big hole of 40 patches for git bisect to find.
>
> On Jun 25, 2006, at 8:10 PM, H. Peter Anvin wrote:
>
>> changes to the
>> main kernel code taken straight from the git history (as it is rather
>> few patches), and additions, grouped by rough divisions.
>
> If they are in the wrong order then that is not good enough.
> The patch names and descriptions are wrong because the are from
> the klibc git tree.
>
>> 01-add-klibckinit-to-maintainers-file.patch
>> 02-remove-root-mounting-code-from-the-kernel-.patch
>> 03-remove-parts-moved-to-kinit.patch
>> 04-support-klibcarch-being-different-from-the-main-arch.patch
> This looks to be 04-powerpc-set-klibc-arch
>
>> 05-need-to-export-ranlib-from-the-top-makefile.patch
>> 06-re-create-root-dev-too-many-architectures-need-it-.patch
> Make the "move stuff i need" and make it first
>
>> 07-eliminate-unnecessary-whitespace-delta-vs-linus-tree.patch
>
> I didn't look, this corrects whitespace before patching? ok early
>
>> 08-klibc-default-initramfs-content-stored-in-usrinitramfs-default.patch
>> 09-kbuild-support-single-targets-for-klibc-and-klibc-programs.patch
>> 10-remove-prototype-for-name-to-dev-t.patch
>> 11-enable-klibc-errlist.patch
> What does this do? No Help, no description, and doesn't trigger
> anything in this patch.
>
>> 12-enable-config-klibc-zlib-now-required-to-build-kinit.patch
> What does this do? No Help, no description, and doesn't do anything
> in the curreent patch
usr/klibc/Kbuild:
libc-$(CONFIG_KLIBC_ZLIB) += \
zlib/adler32.o zlib/compress.o zlib/crc32.o zlib/gzio.o \
zlib/uncompr.o zlib/deflate.o zlib/trees.o zlib/zutil.o \
zlib/inflate.o zlib/infback.o zlib/inftrees.o zlib/inffast.o
At this point, this is required by kinit, which is why it is not
possible to disable.
>> 13-uml-the-klibc-architecture-is-the-underlying-architecture.patch
>> 14-remove-in-kernel-nfsroot-code.patch
>> 15-default-klibcarch--arch.patch
>> 16-sparc64-transmit-arch-specific-options-to-kinit-via-arch-cmd.patch
>> 17-sparc32-transfer-arch-specific-options-to-arch-cmd.patch
> where is x86 and x86_64 ?
> oh you deleted and did not put that back
That's correct; I went around and talked to both x86 and sparc people,
and the x86 people uniformly announced rdev support as being obsolete;
the sparc people, however, continue to rely on being able to get data
from openprom.
>> 18-klibc-inkernel-merge-s390s390x-4.patch
> This patchname is meaningless.
> The description in the patch is worse.
> It looks like it should be 18-s390-set-klibcarch
>
> Hmm... i didn't find the patch removig usr/Makefile, just adding
> usr/Kbuild. usr/Kbuild should be a diff against the existing
> usr/Makefile, whcih can be renamed.
True. Git could work this out.
I have been reluctant to spend too much time on packaging, because I've
still had the issue of continue to maintain the out-of-tree distribution
(which includes usr/Kbuild) indefinitely. I need to spend some more
time scripting.
-hpa
next prev parent reply other threads:[~2006-06-27 19:13 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-26 0:57 [klibc 00/43] klibc as a historyless patchset H. Peter Anvin
2006-06-27 13:12 ` klibc and what's the next step? Roman Zippel
2006-06-27 13:39 ` Jeff Garzik
2006-06-27 16:42 ` [klibc] " Greg KH
2006-06-28 23:46 ` Roman Zippel
2006-06-27 17:01 ` Andi Kleen
2006-06-27 17:11 ` H. Peter Anvin
2006-06-27 17:40 ` Andi Kleen
2006-06-27 17:45 ` H. Peter Anvin
2006-06-27 20:22 ` Joshua Hudson
2006-06-28 5:47 ` H. Peter Anvin
2006-06-29 0:04 ` Roman Zippel
2006-07-03 18:30 ` Rob Landley
2006-07-03 18:46 ` [klibc] " maximilian attems
2006-07-04 1:36 ` Jeff Bailey
2006-07-04 2:02 ` H. Peter Anvin
2006-06-27 14:07 ` Jon Smirl
2006-06-27 14:40 ` Jeff Bailey
2006-06-27 19:47 ` Milton Miller
2006-06-28 23:56 ` Roman Zippel
2006-06-29 0:34 ` H. Peter Anvin
2006-06-29 23:33 ` Roman Zippel
2006-06-30 8:00 ` Gerd Hoffmann
2006-06-30 18:08 ` H. Peter Anvin
2006-06-30 22:58 ` Michael Tokarev
2006-06-30 18:11 ` Pavel Machek
2006-06-30 23:04 ` Michael Tokarev
2006-06-30 23:15 ` H. Peter Anvin
2006-07-01 10:56 ` [klibc] " Jeff Bailey
2006-07-01 15:05 ` Theodore Tso
2006-07-01 20:08 ` Linus Torvalds
2006-07-01 21:58 ` Al Viro
2006-07-01 22:31 ` H. Peter Anvin
2006-07-02 0:05 ` Theodore Tso
2006-07-02 0:17 ` H. Peter Anvin
2006-07-02 0:38 ` Theodore Tso
2006-07-02 0:50 ` H. Peter Anvin
2006-07-01 22:22 ` H. Peter Anvin
2006-07-03 7:23 ` Gerd Hoffmann
2006-07-03 21:36 ` Pavel Machek
2006-07-01 15:22 ` H. Peter Anvin
2006-07-01 15:47 ` Jeff Garzik
2006-06-30 23:32 ` Pavel Machek
2006-07-11 4:48 ` Olaf Hering
2006-07-11 10:29 ` Michael Tokarev
2006-07-11 11:27 ` [klibc] " Olaf Hering
2006-07-11 16:24 ` H. Peter Anvin
2006-07-11 16:40 ` Olaf Hering
2006-07-11 17:05 ` Jeff Garzik
2006-07-11 17:16 ` Olaf Hering
2006-07-11 17:23 ` H. Peter Anvin
2006-07-11 17:30 ` Olaf Hering
2006-07-11 17:46 ` H. Peter Anvin
2006-07-11 18:01 ` Olaf Hering
2006-07-11 18:04 ` H. Peter Anvin
2006-07-11 18:10 ` Olaf Hering
2006-07-11 18:17 ` H. Peter Anvin
2006-07-11 19:15 ` Olaf Hering
2006-07-11 19:29 ` Linus Torvalds
2006-07-11 19:38 ` H. Peter Anvin
2006-07-11 19:51 ` Linus Torvalds
2006-07-11 19:59 ` Jeff Garzik
2006-07-11 20:01 ` Theodore Tso
2006-07-11 20:11 ` Olaf Hering
2006-07-11 20:57 ` H. Peter Anvin
2006-07-11 18:03 ` H. Peter Anvin
2006-07-11 18:06 ` Michael Tokarev
2006-07-11 18:15 ` Olaf Hering
2006-07-11 18:22 ` H. Peter Anvin
2006-07-11 18:53 ` Alan Cox
2006-07-11 18:46 ` H. Peter Anvin
2006-07-11 20:06 ` Olaf Hering
2006-07-11 20:22 ` Olaf Hering
2006-07-11 21:22 ` Greg KH
2006-07-12 16:54 ` Olaf Hering
2006-07-12 16:58 ` Arjan van de Ven
2006-07-12 17:01 ` Olaf Hering
2006-07-12 21:36 ` Greg KH
2006-07-11 17:55 ` Michael Tokarev
2006-07-11 17:46 ` Michael Tokarev
2006-07-11 17:52 ` Olaf Hering
2006-07-11 18:02 ` Michael Tokarev
2006-07-11 10:51 ` Sam Ravnborg
2006-07-11 13:45 ` Theodore Tso
2006-07-11 14:28 ` Michael Tokarev
2006-07-11 15:13 ` [klibc] " Olaf Hering
2006-07-11 15:30 ` Adrian Bunk
2006-07-11 15:47 ` Olaf Hering
2006-07-11 16:21 ` Alan Cox
2006-07-11 14:32 ` Rene Herman
2006-07-12 15:23 ` David Lang
2006-07-13 11:58 ` Pavel Machek
2006-06-27 18:59 ` [klibc 00/43] klibc as a historyless patchset Milton Miller
2006-06-27 19:12 ` H. Peter Anvin [this message]
2006-06-27 20:39 ` Milton Miller
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=44A18335.7020706@zytor.com \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miltonm@bga.com \
/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