Re: [PATCH] bootup: Add built-in kernel command line for x86

2008-08-06 Thread H. Peter Anvin
Tim Bird wrote: One difficulty is that the other arches' command lines are not currently broken, so there's no real incentive to change them. The only thing novel thing I'm adding here is the addition of the leading '!' to allow for an override. This is needed in some x86 cases I'm familiar

Re: [PATCH] bootup: Add built-in kernel command line for x86

2008-08-06 Thread H. Peter Anvin
Matt Mackall wrote: On Wed, 2008-08-06 at 15:48 -0700, H. Peter Anvin wrote: Tim Bird wrote: One difficulty is that the other arches' command lines are not currently broken, so there's no real incentive to change them. The only thing novel thing I'm adding here is the addition of the leading

Re: [PATCH] bootup: Add built-in kernel command line for x86

2008-08-06 Thread H. Peter Anvin
Tim Bird wrote: CONFIG_CMDLINE_OVERRIDE is probably more palatable to other architectures. I'd be OK implementing it with an option, rather than a magic char. I was trying to avoid adding too many options, since many kernel developers prefer fewer options where possible. But the magic char

Re: [PATCH] bootup: Add built-in kernel command line for x86

2008-08-11 Thread H. Peter Anvin
Ingo Molnar wrote: * Tim Bird [EMAIL PROTECTED] wrote: Add support for a built-in command line for x86 architectures. The Kconfig help gives the major rationale for this addition. i have actually used a local hack quite similar to this to inject boot options into bzImages via randconfig -

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread H. Peter Anvin
for this is a system that as far I can tell is nothing other than a toy, specifically designed to show off how little you need to build the kernel. In other words, it's not a practical application, it's a show-off art piece. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

2009-01-02 Thread H. Peter Anvin
was to have access to arbitrary-precision arithmetic -- after it was shown that bc would simply lock up on some systems. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-03 Thread H. Peter Anvin
, and simply hopes that the system utilities that he uses uses an integer size which happens to be big enough. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

2009-01-03 Thread H. Peter Anvin
Rob Landley wrote: I consider this a step up from code with an implicit dependency on a CPAN library. There is no CPAN library in use. Math::BigInt is a standard part of Perl, and the canned values is there only to support extremely old versions of Perl, or weird system configurations, as

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-03 Thread H. Peter Anvin
. Neither is open-coding a bignum operation instead of relying on an existing, validated implementation. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-embedded

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-03 Thread H. Peter Anvin
*does* support 128-bit arithmetic on 64-bit platforms) we didn't end up using it and removed them, although the code to generate them can still be activated. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

2009-01-04 Thread H. Peter Anvin
is explicit about what you will get. The original patch used bc. Unfortunately, it ran into bc bugs -- on some platforms like some of akpm's older test machines it would just hang. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

2009-01-04 Thread H. Peter Anvin
(32 bits). When we get an overflow-less 64-bit implementation, this code will have to be redone, which is not true for a properly done implementation. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-11 Thread H. Peter Anvin
Mark A. Miller wrote: Actually, something that has amused me during this discussion, is that right now, the latest stable Perl (5.8.8) does not compile correctly on a uclibc host... The latest stable Perl is 5.10.0, and the latest of the 5.8 series is 5.8.9. -hpa -- H. Peter

Re: [Patch] Wait for console to become available, ver 3

2009-04-17 Thread H. Peter Anvin
David VomLehn wrote: + consoledelay=mS [KNL] Wait up to mS milliseconds for the a preferred + console to be registered, then continue. Useful for + systems where a console may not be plugged in, such as + for USB serial

Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit

2009-06-16 Thread H. Peter Anvin
(sometimes in the form of a boot loader) so Linux rarely sees it. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord

Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit

2009-06-17 Thread H. Peter Anvin
that can save a penny from your last sentence... -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo

Re: [PATCH 3/5] Add support for LZO-compressed kernels

2009-07-22 Thread H. Peter Anvin
kevin.gran...@gmail.com wrote: So for a compression ratio that is still relatively close to gzip, it's much faster to extract, at least in that case. Is that time to run the extraction algorithm, or time to read in image from media and extract? I think the time to read from the media

Re: [PATCH 5/5] Add support for LZO-compressed kernels on x86

2009-07-29 Thread H. Peter Anvin
. Peter Anvin h...@zytor.com Since the patchset otherwise isn't really x86-related it probably makes more sense to pass this through the kbuild tree, or perhaps via akpm, rather than -tip? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body

Re: [PATCH 6/6] Add LZO compression support for initramfs and old-style initrd

2009-08-03 Thread H. Peter Anvin
Truncated help text... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: [PATCH 5/6] Add support for LZO-compressed kernels on x86

2009-08-03 Thread H. Peter Anvin
/x86/Kconfig |1 + arch/x86/boot/compressed/Makefile |5 - arch/x86/boot/compressed/misc.c |4 3 files changed, 9 insertions(+), 1 deletions(-) Acked-by: H. Peter Anvin h...@zytor.com -hpa -- H. Peter Anvin, Intel Open Source Technology Center

Re: [PATCH 1/6] lib/decompress_*: only include linux/slab.h if STATIC is not defined

2009-08-04 Thread H. Peter Anvin
On 08/04/2009 05:47 PM, Phillip Lougher wrote: Andrew Morton wrote: On Mon, 3 Aug 2009 16:58:16 +0200 Albin Tonnerre albin.tonne...@free-electrons.com wrote: These includes were added by 079effb6933f34b9b1b67b08bd4fd7fb672d16ef to fix the build when using kmemtrace. However this is not

Re: [PATCH 3/6] Add support for LZO-compressed kernels

2009-08-04 Thread H. Peter Anvin
On 08/04/2009 04:00 PM, Andrew Morton wrote: 0.24 seconds booting speedup sounds pretty thin. Adding a new decompression format will introduce more configuration/build/deployment complexities. How do we justify this? Keep in mind this may be out of a 3-5 second boot budget. -hpa

Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM

2009-08-07 Thread H. Peter Anvin
On 08/07/2009 01:00 PM, Russell King - ARM Linux wrote: On Fri, Aug 07, 2009 at 03:55:24PM +0200, Albin Tonnerre wrote: That's true for the actual kernel image, but not for the bootstrap code we use when compiling compressed kernels. arch/arm/boot/compressed/Makefile uses libgcc, unless I'm

Re: [PATCH 4/6] Add support for LZO-compressed kernels for ARM

2009-08-13 Thread H. Peter Anvin
On 08/13/2009 02:30 AM, Albin Tonnerre wrote: On Tue, Aug 11, 2009 at 09:31:25AM -0700, H. Peter Anvin wrote : On 08/11/2009 09:27 AM, Albin Tonnerre wrote: So I guess the only options left are either define a dummy raise() function, or get rid of the divisions like Alain Knaff did in his

Re: [PATCH RFC 1/3] Decompressors: Add XZ decompressor module

2010-11-24 Thread H. Peter Anvin
On 11/24/2010 02:50 PM, H. Peter Anvin wrote: Logically it should be an additional CONFIG option like we currently have for the other compression formats. And so it is (it's in the latter patches). -hpa -- To unsubscribe from this list: send the line unsubscribe linux-embedded

Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.

2011-11-20 Thread H. Peter Anvin
On 11/18/2011 11:37 AM, David Daney wrote: From: David Daney david.da...@cavium.com Using this build-time sort saves time booting as we don't have to burn cycles sorting the exception table. If we're going to do this at build time, I would suggest using a collisionless hash instead. The

Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.

2011-11-20 Thread H. Peter Anvin
On 11/20/2011 03:26 PM, H. Peter Anvin wrote: On 11/18/2011 11:37 AM, David Daney wrote: From: David Daney david.da...@cavium.com Using this build-time sort saves time booting as we don't have to burn cycles sorting the exception table. If we're going to do this at build time, I would

Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.

2011-11-20 Thread H. Peter Anvin
On 11/20/2011 03:28 PM, David Woodhouse wrote: On Sun, 2011-11-20 at 15:26 -0800, H. Peter Anvin wrote: If we're going to do this at build time, I would suggest using a collisionless hash instead. The lookup time for those are O(1), but they definitely need to be done at build time