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 with, but I've haven't seen
any cases where it would be useful for other arches.
(not to say they don't exist - I just haven't seen them.)



Note that it could just as easily be done with a CONFIG_CMDLINE_OVERRIDE 
option, since the initial reason for a magic character was to be able to 
provide both prefix and suffix splicing.


CONFIG_CMDLINE_OVERRIDE is probably more palatable to other architectures.

-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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 '!' to allow for an override.  This is needed
in some x86 cases I'm familiar with, but I've haven't seen
any cases where it would be useful for other arches.
(not to say they don't exist - I just haven't seen them.)

Note that it could just as easily be done with a CONFIG_CMDLINE_OVERRIDE 
option, since the initial reason for a magic character was to be able to 
provide both prefix and suffix splicing.


You're right, I had forgotten about the suffix splicing and my brain is
a bit foggy on what motivated it.



Well, prefix = bootloader overrides; suffix = builtin overrides.


CONFIG_CMDLINE_OVERRIDE is probably more palatable to other architectures.


Yes, though I doubt we're in danger of introducing any real backwards
compatibility issues with the magic '!' at the beginning.


Well, it does if we want to make this a generic feature, which I believe 
we should.


-hpa

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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 makes the code less straightforward.

If we ever move towards supporting both prefix and suffice splicing (or
even complicated in-the-middle splicing), then the magic char is
easier to develop into that.  But so far, I can only come up with
reasonable cases for append and override, and I don't want to add
superfluous handling for non-existent use cases.


I think I agree, and the override option would make it easier to make 
generic.


-hpa

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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 - so i would find this feature 
rather useful.


a small observation:


+   /* append boot loader cmdline to builtin, unless builtin overrides it */
+   if (builtin_cmdline[0] != '!') {
+   strlcat(builtin_cmdline,  , COMMAND_LINE_SIZE);
+   strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
+   strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+   } else {
+   strlcpy(boot_command_line, builtin_cmdline[1],
+   COMMAND_LINE_SIZE);
+   }


the default branch changes existing command lines slightly: it appends a 
space to them. This could break scripts that rely on the precise 
contents of /proc/cmdline output. (i have some - they are arguably 
dodgy)


Best would be to make it really apparent in the code that nothing 
changes if this config option is not set. Preferably there should be no 
extra code at all in that case.




I would like to see this:

#ifdef CONFIG_BUILTIN_CMDLINE
# ifdef CONFIG_BUILTIN_CMDLINE_OVERRIDE
strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
# else
if (boot_command_line) {
strlcat(builtin_cmdline,  , COMMAND_LINE_SIZE);
strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
}
# endif
#endif

-hpa


--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-01-02 Thread H. Peter Anvin
Sam Ravnborg wrote:
 Hi Wookey.
 
 Given the
 simplicitly of these patches I can't see any reason not to put them
 in
 
 Please do NOT do the mistake and think this the same thing.
 
 Rob's patch simplyfy the timecost stuff - and will be applied on
 this merit alone assuming comments will be addressed.
 
 But the serie rased anohter topic: shall we ban use of perl
 for generating a kernel.
 And this is what primary is discussed and the outcome of
 that discussion will not prevent patches that stands on their
 own to be applied.
 

My personal opinion on this is that this is ridiculous.  Given that you
need gcc, binutils, make etc. to build the kernel, and this is more than
inherent, you have to have a pretty bloody strangely constrained system
to disallow Perl, which is as close to a standard 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's a show-off art piece.

-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://vger.kernel.org/majordomo-info.html


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

2009-01-02 Thread H. Peter Anvin
Rob Landley wrote:
 
 You mean The new shell script is much simpler, about 1/4 the size, runs on 
 Red Hat 9 from 2003, and isn't perl? :)
 

And introduces unclear environment dependencies depending on how
external utilities are implemented.

The whole point of 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 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://vger.kernel.org/majordomo-info.html


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

2009-01-03 Thread H. Peter Anvin
Sam Ravnborg wrote:
 With respect to your three patches the plan is to:
 - add the updated timeconst patch to kbuild-next

If you add this, you take the responsibility for the breakages that will
occur.  The reason his patch is simpler is because he removes the
arbitrary-precision 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 line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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 a
belt-and-suspenders measure.

-hpa
--
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://vger.kernel.org/majordomo-info.html


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

2009-01-03 Thread H. Peter Anvin
Rob Landley wrote:
 
 The new patches have *more* environmental
 dependencies than that ever did.
 
 Could you please be a little more specific?
 

In this case, you're assuming that every version of every shell this is
going to get involved with is going to do math correctly with the
requisite precision, which is nowhere guaranteed, I'm pretty sure.

 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 be a starting point.
 
 This doesn't _need_ bignum support.  It maxes out around 72 bits and the 
 _result_ can't use more than about $SHIFT bits because you're dividing by the 
 amount you shifted, so just chop off the bottom 32 bits, do a normal 64 bit 
 division on the top (it has to fit), and then do the same division on the 
 appropriate shifted remainder, and combine the results.  This is easy because 
 when the shift _is_ 32 bits or more, the bottom 32 bits all have to be zeroes 
 so you don't even have to mask and add, just shift the remainder left 32 bits 
 so you 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 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://vger.kernel.org/majordomo-info.html


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

2009-01-03 Thread H. Peter Anvin
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 shell
 version not do the same thing?
 

The Perl version uses Math::BigInt, a Perl standard module (with a
canned-values fallback for ancient or minimal Perl installations) to do
arbitrary precision arithmetic.

The original version also produced constants that could be used with
64-bit values, but since gcc doesn't support 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.  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://vger.kernel.org/majordomo-info.html


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

2009-01-04 Thread H. Peter Anvin
Alan Cox wrote:
 I note that sed and printf and such are all susv3.  I have an explicit test 
 for 32 bit math in the script that cares, and this worked in Red Hat 9 circa 
 2003.
 
 If you are trying to do arbitary precision maths using standard posix
 tools 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
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://vger.kernel.org/majordomo-info.html


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

2009-01-04 Thread H. Peter Anvin
Rob Landley wrote:
 
 C) The only calculation which can overflow 64 bits (the ADJ32 one) turns out 
 not to need arbitrary precision math, just 72 bits, and if it ever uses more 
 than 32 then bottom 32 are all zero before the divide so you can do it in 
 three lines.
 

... 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 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://vger.kernel.org/majordomo-info.html


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 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://vger.kernel.org/majordomo-info.html


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 devices.
+


Pet peeve:

The symbol for millisecond is ms.  mS is a unit of conductance, 
millisiemens.


-hpa
--
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://vger.kernel.org/majordomo-info.html


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

2009-06-16 Thread H. Peter Anvin
Ralf Baechle wrote:
 
 I2C or similar busses can be a particularly annoying if they contain
 essential configuration information such as memory size which is needed
 long before anything else.  So for far a common solution is that platforms
 are carrying a private (aka redundant, ugly) early-i2c system that's just
 about sufficient for this purpose.
 

For what it's worth, this is true for pretty much ALL systems with
removable memory modules, since Serial Presence Detect (SPD) is
electrically equivalent to I2C.

However, on most systems, even embedded, 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 linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-06-17 Thread H. Peter Anvin
Ralf Baechle wrote:

 However, on most systems, even embedded, bringing up memory falls on
 firmware (sometimes in the form of a boot loader) so Linux rarely sees it.
 
 There are embedded systems were the firmware does not provide a usuable
 memory map or where that is plain broken.  Or Linux with some extra init
 code serves as the firmware.  Often there is a single serial EEPROM for
 the entire system.  If there is an atrocity that can save a penny it will
 be commited at least in the embedded world.
 

Rarely is certainly not 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: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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 
would tend to dominate the decompression time.
Either way, could you provide the other time for each algorithm in order 
to give a sense of how this might scale to other CPU speeds/media read 
speeds?




If you have very slow media, you probably want to use LZMA.  If you have 
a very slow CPU and comparatively fast media, LZO might be a good 
option... I have heard people asking for *uncompressed* kernels for this 
reason, but LZO runs at a significant fraction of memcpy() speed.


-hpa
--
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://vger.kernel.org/majordomo-info.html


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

2009-07-29 Thread H. Peter Anvin
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 albin.tonne...@free-electrons.com

Acked-by: H. 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 of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-08-03 Thread H. Peter Anvin
On 08/03/2009 07:58 AM, Albin Tonnerre wrote:
  
 +config INITRAMFS_COMPRESSION_LZO
 + bool LZO
 + depends on RD_LZO
 + help
 +   Its compression ratio is the poorest among the four. The kernel
 +   size is about about 10% bigger 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 message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-08-03 Thread H. Peter Anvin
On 08/03/2009 07:58 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 albin.tonne...@free-electrons.com
 ---
  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 h...@zytor.com

-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://vger.kernel.org/majordomo-info.html


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 necessary when
 used to create a compressed kernel, and actually creates issues (brings
 a lot of things unavailable in the decompression environment), so don't
 include it if STATIC is defined.


 The description actually creates issues (brings a lot of things
 unavailable in the decompression environment) is inadequate.  Please
 describe te problem this patch fixes more completely so that others
 (ie: me) can decide whether this patch is needed in 2.6.32, 2.6.31.
 2.6.30, ...

 This patch conflicts heavily with

 http://userweb.kernel.org/~akpm/mmotm/broken-out/bzip2-lzma-remove-nasty-uncompressed-size-hack-in-pre-boot-environment.patch

 What should we do about that?
 
 
 What do you normally do in this situation?  I'm happy to send a revised
 bzip2-lzma-remove-nasty-uncompressed-size-hack-in-pre-boot-environment.patch
 
 that would apply cleanly on-top of Alvin's patch, but, this will obviously
 create dependencies on his patch being applied.
 

The general principle is that if A alone creates a more functional
environment than B alone, then B should be applied on top of A, and vice
versa.  This is especially so if A is a stable candidate.

It *sounds* like your patch is B here, but I am not sure from the
description.

-hpa
--
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://vger.kernel.org/majordomo-info.html


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
--
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://vger.kernel.org/majordomo-info.html


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 overlooking something here:

   arm-unknown-linux-uclibcgnueabi-ld -EL--defsym zreladdr=0x20008000
   --defsym initrd_phys=0x2041 --defsym params_phys=0x2100 -p
   --no-undefined -X
   
 /home/albin/x-tools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/libgcc.a
   -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o
   arch/arm/boot/compressed/piggy.gzip.o arch/arm/boot/compressed/misc.o -o
   arch/arm/boot/compressed/vmlinux
 
 It's because libgcc appears in the wrong place in the command line, and
 due to the way kbuild works, we can't get it into the right place easily.
 
 Linkers are sensitive to the order of archives on the command line - its
 pointless having an archive as the first file argument because none of
 the contained objects will ever be pulled in.
 
 Sam - any ideas how to solve this?

Can we use the group feature of ld for this?

-hpa

--
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://vger.kernel.org/majordomo-info.html


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 patch ?

 Define a dummy raise, get rid of the divisions, or provide your own
 division function (there is probably one in the kernel already...)
 
 Yes, there's such a function in arch/arm/lib/lib1funcs.S, which in turns
 requires the __div0 symbol, defined in arch/arm/kernel/traps.c, and this one
 cannot be used as it brings plenty of symbols that aren't available in the
 pre-boot environment. So anyway, we have to define our own symbols there. 
 Either
 we use libgcc and define raise(), or lib1funcs and define __div0().
 

I would go with the variant in the kernel, as being a known quantity.

Your __div0 function can just loop forever.

-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://vger.kernel.org/majordomo-info.html


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 in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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 lookup time for those are O(1), but
they definitely need to be done at build time.

-hpa

--
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://vger.kernel.org/majordomo-info.html


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 suggest using a
 collisionless hash instead.  The lookup time for those are O(1), but
 they definitely need to be done at build time.
 

I have some code for generating these kinds of tables, they just need to
be hooked up.  I will dig it up later today or tomorrow.

-hpa

--
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://vger.kernel.org/majordomo-info.html


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. 
 
 Is the lookup time really an issue?
 

Probably not a big one (in most scenarios), but with better exception
handling it might stretch the usability of exceptions.  The bigger thing
is that once you're doing a build-time special handler for this
*anyway*, you might as well drive the cost of the lookup to functionally
zero.

-hpa
--
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://vger.kernel.org/majordomo-info.html