Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
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.
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.
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
Re: [PATCH RFC 1/3] Decompressors: Add XZ decompressor module
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 4/6] Add support for LZO-compressed kernels for ARM
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 4/6] Add support for LZO-compressed kernels for ARM
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 1/6] lib/decompress_*: only include linux/slab.h if STATIC is not defined
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
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 6/6] Add LZO compression support for initramfs and old-style initrd
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
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 5/5] Add support for LZO-compressed kernels on x86
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 3/5] Add support for LZO-compressed kernels
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: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
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: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
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: [Patch] Wait for console to become available, ver 3
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: PATCH [0/3]: Simplify the kernel build by removing perl.
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 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
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
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.
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
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.
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.
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 [0/3]: Simplify the kernel build by removing perl.
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
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] bootup: Add built-in kernel command line for x86
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
