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 nee
On 11/20/2011 03:26 PM, H. Peter Anvin wrote:
> On 11/18/2011 11:37 AM, David Daney wrote:
>> From: David Daney
>>
>> Using this build-time sort saves time booting as we don't have to burn
>> cycles sorting the exception table.
>>
>
> If we'r
On 11/18/2011 11:37 AM, David Daney wrote:
> From: David Daney
>
> 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 lookup time for tho
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 "unsu
On 11/24/2010 02:25 PM, Andrew Morton wrote:
>>
>> This patch: Add the main decompression code (xz_dec), testing
>> module (xz_dec_test), wrapper script (xz_wrap.sh) for the xz
>> command line tool, and documentation. The xz_dec module is
>> enough to have a usable XZ decompressor e.g. for Squashfs
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 r
ction (there is probably one in the kernel already...)
-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
Has anyone an idea on
> this ?
>
raise() gets called by libgcc to handle division by zero.
-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-e
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, unl
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.
On 08/04/2009 05:47 PM, Phillip Lougher wrote:
> Andrew Morton wrote:
>> On Mon, 3 Aug 2009 16:58:16 +0200
>> Albin Tonnerre wrote:
>>
>>> These includes were added by 079effb6933f34b9b1b67b08bd4fd7fb672d16ef to
>>> fix the build when using kmemtrace. However this is not necessary when
>>> used t
gt; arch/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
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I
er than gzip; however its speed
> +
> endchoice
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
On 07/22/2009 07:01 AM, Albin Tonnerre wrote:
> This is the third and last part of the patch, which contains the
> necessary changes to the x86 Kconfig and boot/compressed to allow the
> use of this new compression method
>
> Signed-off-by: Albin Tonnerre
Acked-by: H. Peter An
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 med
t "never". Quite on the contrary. Also, I
think you can remove "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: sen
ed, bringing up memory falls on
firmware (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 li
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 dev
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.
-hp
.. for the current code (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 beh
s just use dc. That way the standard 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
H. Peter Anvin wrote:
> Jamie Lokier wrote:
>> Related query:
>>
>> Does the Perl script being replaced use 64-bit arithmetic? Because
>> many Perl installations only do 32-bit arithmetic.
>>
>> If the Perl version works in 32-bit arithmetic, why does the
ort 128-bit arithmetic on
32-bit platforms (gcc *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.
ou can continue the divide.
>
> Pulling out perl isn't always a good alternative to thinking about the
> problem.
>
Neither is open-coding a bignum operation instead of relying on an
existing, validated implementation.
-hpa
--
H. Peter Anvin, Intel Open Source
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,
tch using bc had less dependencies, but bc failed on some
platforms, mysteriously. The new patches have *more* environmental
dependencies than that ever did.
Third, if someone actually cares to do it right, I have a smallish
bignum library at http://git.zytor.com/?p=lib/pbn.git;a=summary that
might
ision arithmetic, 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 li
why that script was written in Perl 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 unsubscri
d Unix utility you can
get without making it into SuS.
The only *real* motivation I have seen 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&#
Ingo Molnar wrote:
* Thomas Petazzoni <[EMAIL PROTECTED]> wrote:
This patch adds some configuration options that allow to compile out
CPU vendor-specific code in x86 kernels (in arch/x86/kernel/cpu). The
new configuration options are only visible when CONFIG_EMBEDDED is
selected, as they are
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 -
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 m
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 he
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
Rob Landley wrote:
Except for the minor fact that most early boot debugging happens long
before the console subsystem is even available..
Isn't that why CONFIG_EARLY_PRINTK was written? (And I mentioned Linus's hack
using the RTC to see how far the _really_ early stuff got.)
Don't think tha
Rob Landley wrote:
Actually, lots have frame buffers these days.
Cell phones, for instance.
Sure, but do you want to use them as consoles?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
Tim Bird wrote:
With CONSOLE_TRANSLATIONS turned off, this saves about 6K
on my kernel configured for an ARM development board (OMAP
5912 OSK). In embedded products I'm familiar with,
console translations are not needed.
On most embedded products I'm familiar with, you wouldn't have virtual
c
37 matches
Mail list logo
