Re: [PATCH] bootup: Add built-in kernel command line for x86
* 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.
Ingo
--
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 1/1] [x86] Configuration options to compile out x86 CPU support code
* 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 mostly interesting for space savings reasons. An example of size saving, on x86 with only Intel CPU support: text data bss dec hex filename 1125479118760 212992 1457231 163c4f vmlinux.old 1121355116536 212992 1450883 162383 vmlinux -4124 -2224 0 -6348 -18CC +/- However, I'm not exactly sure that the Kconfig wording is correct with regard to !64BIT / 64BIT. applied to tip/x86/cpu, thanks Thomas. (I've done a trivial cleanup: converted the macro to an inline.) Peter, do you like this version of the patch or would you like further improvements? Ingo -- 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 1/1] [x86] Configuration options to compile out x86 CPU support code
-tip testing found a couple of build failures: LD .tmp_vmlinux1 arch/x86/lib/lib.a(usercopy_32.o): In function `__copy_to_user_ll': (.text+0x11e): undefined reference to `movsl_mask' arch/x86/lib/lib.a(usercopy_32.o): In function `__copy_from_user_ll': (.text+0x1fa): undefined reference to `movsl_mask' arch/x86/lib/lib.a(usercopy_32.o): In function `__copy_from_user_ll_nozero': (.text+0x2d6): undefined reference to `movsl_mask' arch/x86/lib/lib.a(usercopy_32.o): In function `copy_from_user': (.text+0x5ac): undefined reference to `movsl_mask' arch/x86/lib/lib.a(usercopy_32.o): In function `copy_to_user': (.text+0x6bf): undefined reference to `movsl_mask' make: *** [.tmp_vmlinux1] Error 1 with: http://redhat.com/~mingo/misc/config-Fri_Aug_15_16_35_03_CEST_2008.bad and: arch/x86/kvm/built-in.o: In function `paging64_cmpxchg_gpte': mmu.c:(.text+0xa80d): undefined reference to `cmpxchg_486_u64' with: http://redhat.com/~mingo/misc/config-Fri_Aug_15_16_27_47_CEST_2008.bad reverting your change solved both of them. i still have the commit in tip/x86/cpu so please send a delta fix ontop of your previous patch once you figure out the problem. Thanks, Ingo -- 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] [x86] Move cmpxchg fallbacks to a generic place
* Thomas Petazzoni [EMAIL PROTECTED] wrote: arch/x86/kernel/cpu/intel.c defines a few fallback functions (cmpxchg_*()) that are used when the CPU doesn't support cmpxchg and/or cmpxchg64 natively. However, while defined in an Intel-specific file, these functions are also used for CPUs from other vendors when they don't support cmpxchg and/or cmpxchg64. This breaks the compilation when support for Intel CPUs is disabled. This patch moves these functions to a new arch/x86/kernel/cpu/cmpxchg.c file, unconditionally compiled when X86_32 is enabled. Signed-off-by: Thomas Petazzoni [EMAIL PROTECTED] applied both fixes to tip/x86/cpu, thanks Thomas. I also flipped it around with the cpu-id reduction patch, so that it remains bisectable. The new commit IDs in -tip are: 8bfcb39: x86: make movsl_mask definition non-CPU specific 774400a: x86: move cmpxchg fallbacks to a generic place 8d02c21: x86: configuration options to compile out x86 CPU support code Ingo -- 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: Wait for console to become available, v3.2
* David VomLehn dvoml...@cisco.com wrote: Parallelization to improve boot times has been successful enough that race conditions now exist between the init_post() open of /dev/console and initialization of the console device. When this occurs, opening /dev/console fails and any applications inherited from init have no standard in/out/error devices. This is expected behavior if no console device is available, but quite unfortunate in the case where the console is just a bit slow waking up. Some buses, such as USB, offer no guarantees about how long it takes to discover devices, so there is no reliable way to distinguish between a missing console and a slow one. The pragmatic approach taken in this patch is to wait for a while to see if a console shows up, and just go on if it doesn't. The default delay is 1000 msec (1 second). This value is conjured out of thing air; any suggestions for a value that more closely approximates the effective delays from the olden days before USB consoles starting failing are more than welcome. hm, this really seems like a bad hack and a workaround to me and as such it is not really an acceptable solution. The proper approach would be to use one of the async_synchronize*() facilities in kernel/async.c to properly order the opening of the console with device init. Certain subsystems like storage (SCSI, libata, mount code and modules) has already been extended to this scheme. So i think the right approach, if you want to speed up bootup, would be to extend the same concepts to console discovery, init and open methods. Ingo -- 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: Wait for console to become available, v3.2
* Arjan van de Ven ar...@infradead.org wrote: On Tue, 21 Apr 2009 08:43:46 +0200 Ingo Molnar mi...@elte.hu wrote: The proper approach would be to use one of the async_synchronize*() facilities in kernel/async.c to properly order the opening of the console with device init. Unfortunately this is not the answer. First of all, USB does not use the async_* infrastructure, so it does not do anything. [ Of course it does not. Two kernel cycles ago nothing had any async infrastructure ;-) We barely have any use of it today. But cases like this are the way to extend its use. ] But more importantly... USB *CANNOT* do this fundamental operation. USB does not have the capability to know when you have seen all devices that are connected. Devices just show up a random amount of time after you turn the power on for the bus there's no and now we've seen all operation. Yes - and this is fundamentally true of any hotplug bus design. Nevertheless the wish has been expressed to wait for such a device to become available, in this very thread we are discussing. What i'm saying is: instead of wait 2000 msecs, maybe it works out hack, there should be a proper sleep+event based approach to the same. With perhaps a _timeout_ for the no console arrived negative case as well. (which timeout can be set to zero in the I _know_ there's no console around.) Do you see the fundamental design difference between the two solutions? Ingo -- 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] PM: Hide CONFIG_PM from users
* Mark Brown broo...@opensource.wolfsonmicro.com wrote: It is very rare to find a current system which is both sufficiently resource constrained to want to compile out power management support and sufficiently power insensitive to be able to tolerate doing so. Since having the configuration option requires non-zero effort to maintain, with ifdefery in most drivers, but it is used with vanishing rarity it is simpler to just remove the option. Well, either make it dependent on CONFIG_EXPERT or remove the option altogether. Thanks, Ingo -- 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] Remove CONFIG_PM altogether, enable power management all the time
* Rafael J. Wysocki r...@sisk.pl wrote: I'd appreciate it if people could review/test it and drop their comments. Thanks, Rafael --- arch/x86/xen/Kconfig |2 +- drivers/acpi/Kconfig |1 - drivers/acpi/bus.c |4 +--- drivers/acpi/internal.h|6 ++ drivers/acpi/sleep.c | 13 +++-- drivers/base/power/Makefile|3 +-- drivers/net/e1000e/netdev.c|8 drivers/net/pch_gbe/pch_gbe_main.c |2 +- drivers/pci/pci-driver.c |4 ++-- drivers/scsi/Makefile |2 +- drivers/scsi/scsi_priv.h |2 +- drivers/scsi/scsi_sysfs.c |2 +- drivers/usb/core/hcd-pci.c |4 ++-- include/acpi/acpi_bus.h|2 +- include/linux/pm.h |2 +- kernel/power/Kconfig | 29 +++-- 16 files changed, 37 insertions(+), 49 deletions(-) Ok, there's some real bang for bucks in this patch, nice! It's a beginning. Reviewed-by: Ingo Molnar mi...@elte.hu Also, i've Cc:-ed Linus, to check whether the idea to make power management a permanent, core portion of Linux has any obvious downsides we missed. Rafael, could you do a defconfig-ish x86 build with and without CONFIG_PM, and post the 'size vmlinux' comparison - so that we can see the size difference? We make some things CONFIG_EXPERT configurable just to enable folks who *really* want to cut down on kernel size to configure it out. Note that those usecases, even if they want a super-small kernel, might not care about PM at all while they care about size: small boot kernels in ROMs, or simple devices where CPU-idling implies deep low power mode, etc. So the vmlinux size comparisons would be needed really. If it's 5k nobody will care. If it's 50k-100k that's borderline. In the other side of the scale we have the 1500+ #ifdef CONFIG_PM lines strewn around the kernel source, and the frequent !PM build breakages. Ingo -- 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] Remove CONFIG_PM altogether, enable power management all the time
* Tim Bird tbird...@gmail.com wrote: On Tue, Feb 8, 2011 at 4:21 AM, Ingo Molnar mi...@elte.hu wrote: Rafael, could you do a defconfig-ish x86 build with and without CONFIG_PM, and post the 'size vmlinux' comparison - so that we can see the size difference? We make some things CONFIG_EXPERT configurable just to enable folks who *really* want to cut down on kernel size to configure it out. I'm one of those people who *really* wants to cut down the kernel size. I've recently worked on a product where the kernel RAM budget is ~1M. Did that kernel have CONFIG_PM disabled? Note that those usecases, even if they want a super-small kernel, might not care about PM at all while they care about size: small boot kernels in ROMs, or simple devices where CPU-idling implies deep low power mode, etc. So the vmlinux size comparisons would be needed really. If it's 5k nobody will care. I care about 5K. (But honestly, I don't actively hunt stuff less than 10K in size, because there's too many of them to chase, currently). The numbers that Frank Rowand sent show 40K+: | | For 2.6.38-rc4, x86_64, CONFIG_NR_CPUS=4: | | size vmlinux |text data bss dec hex filename | | 6553910 3555020 9994240 20103170 132c002 vmlinuxwithCONFIG_PM | 6512652 3553116 9994240 20060008 1321768 vmlinuxwithout CONFIG_PM | | 41258 1904 0 43162 delta | Thanks, Ingo -- 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
