Re: [PATCH] PM: Hide CONFIG_PM from users
* Mark Brown 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 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 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 wrote: > On Tue, Feb 8, 2011 at 4:21 AM, Ingo Molnar 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
Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
* Denys Vlasenko <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > Here is the update against current Linus tree, > rolled up into one patch. > > James Bottomley suggested a different naming scheme: > instead of swapping parts (.text.head -> .head.text), > prepend .kernel to our special section names. > This patch implements his idea. > > ppc and v850 are dropped per comments from arch people. > parisc and x86 had minor fixes. x86 fix added proper > executable bits to a section: > > -.section ".text.head" > +.section ".kernel.text.head","ax",@progbits > > Does arch/m68k/kernel/sun3-head.S need the same fix? > > The patch is run-tested on x86_64. > > I would like to ask arch maintainers to ACK/NAK this patch, > and Andrew to act accordingly. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> could you please put the ax/progbits fix in front of the queue so that it becomes bisectable and so that the later patches keep their "it should not change anything" property? I.e. do not mix small fixlets into a large set of "no change" patches - split them out in front. This is really important for the x86 bits as linker script changes tend to be quite fragile. 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] 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] bootup: Add built-in kernel command line for x86 (v2)
* Tim Bird <[EMAIL PROTECTED]> wrote: > Allow x86 to support a built-in kernel command line. The built-in > command line can override the one provided by the boot loader, for > those cases where the boot loader is broken or it is difficult to > change the command line in the the boot loader. > > Signed-off-by: Tim Bird <[EMAIL PROTECTED]> applied to tip/x86/commandline for v2.6.28 merging - thanks Tim! 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] bootup: Add built-in kernel command line for x86 (v2)
* Tim Bird <[EMAIL PROTECTED]> wrote: > + To compile command line arguments into the kernel, > + set this option to 'Y', then fill in the FYI, this tab-to-space whitespace error caused this build failure in -tip testing: arch/x86/Kconfig:1500: unknown option "set" arch/x86/Kconfig:1501: unknown option "the" arch/x86/Kconfig:1503: unknown option "Systems" arch/x86/Kconfig:1504: unknown option "should" arch/x86/Kconfig:1519: unknown option "In" arch/x86/Kconfig:1520: unknown option "by" arch/x86/Kconfig:1521: unknown option "file" i fixed it up. This line was broken too: > + In most cases, the command line (whether built-in or provided 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 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
* David Brownell wrote: > On Monday 20 April 2009, Ingo Molnar 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. > > Stepping back a moment from "how" to make sure "what" is agreed > on. > > I think I see three scenarios here: > > - Classic PC or server, where there's a meaningful console; > > - Deeply embedded systems, where there isn't; > > - Development stages of "deeply embedded", where there *may* be >one. > > If that's correct, then async_synchronize() isn't a full answer... > > I think a fair number of cases can be papered over with a serial > console with no hardware flow control, which isn't hooked up to > anything. Maybe the board needs a test/development jig to get > one; without it, the "console" bits spill out into the aether. > Linux can dump bits to ttyS0, which will act like /dev/null. > > But the problem case here seems to be one where such un-hooked-up > serial ports are not realistic options. Which is why the > regression in USB console functionality has been troublesome. > > Is that correct? Not sure i understand the complication. The practical issue addressed by this particular patch i've replied to is that if /dev/console is sys_open()-ed by an app "too early", an error code is returned and subsequently user-space (and all its child tasks) remain console-less. Whether the console has flow control or not is immaterial. Initialization sequence ordering details should be transparent as far as sys_open() of a console is concerned. If there is _no console_, then obviously there's nothing to wait for and the async wait will succeed immediately. The console driver still returns an error on sys_open() but that is expected behavior. The solution proposed in the patch i'm replying to is a boot flag that causes the kernel to wait N milliseconds. This is incorrect and wrong on several levels. If the console can be initialized via a proper handshake that should be exposed precisely - we should not wait neither longer nor shorter than needed. _If_ there's no proper handshake and a magic delay is needed (because there's some hardware-internal delay needed at init time) before the console can be used then that should be in the console driver itself and the async-wait will wait for that automatically. But never should we have delays like this in generic code. Regardless of embedded versus server versus desktop issues. 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 wrote: > On Tue, 21 Apr 2009 08:43:46 +0200 > Ingo Molnar 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: Wait for console to become available, v3.2
* Jamie Lokier wrote:
> Ingo Molnar wrote:
> > * Arjan van de Ven wrote:
> > > 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.
>
> It's not fundamental, for devices you know are plugged in at boot.
> All it takes is for the bus to support a synchronous "enumerate
> all" procedure. That _could_ involve a timeout, but there are
> better ways. But not for USB.
>
> > 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".)
>
> Isn't the proposed code doing exactly that? It sleeps waiting for
> a console, with a timeout of X msecs. If a console arrives before
> that, doesn't it wake immediately?
Yes - except that the timeout is aspecific. I.e. we'll time out even
if the delay happens not due to a device arriving too late (or not
arriving at all), but due to some earlier init step taking an
unexpectedly long time.
> > Do you see the fundamental design difference between the two
> > solutions?
>
> The only difference I see is: If you asked for a USB console, the
> timeout should begin relative to when the USB host driver kicks
> the bus, not the first /dev/console open.
>
> Conceptually the timeout is a USB characteristic, not a generic
> console one.
>
> For other (non-USB) devices which might take a while to
> initialise, it should work as you describe. E.g. an ethernet TCP
> console should register ("i'm trying to give you a console")
> followed by ("got it") or ("failed, carry on without me").
I guess we could live with this one too but still it feels wrong to
me. It would be much better to push the decision to time out into
individual console drivers.
Also, if we end up doing this - the patch, as proposed right now,
appears to add a default 1000 msecs sleep to every __tty_open()
call:
+config PRINTK_CONSOLE_WAIT
+ int "Default number of milliseconds to wait for console device"
+ default 1000
Does this only delay init during a console-less bootup - or are
there other later apps that might trigger the delay?
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
