[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080628043833.GD25492@linux-sh.org>
Date: Sat, 28 Jun 2008 13:38:33 +0900
From: Paul Mundt <lethal@...ux-sh.org>
To: monstr@...nam.cz
Cc: linux-kernel@...r.kernel.org, arnd@...db.de,
linux-arch@...r.kernel.org, stephen.neuendorffer@...inx.com,
John.Linn@...inx.com, john.williams@...alogix.com, matthew@....cx,
will.newton@...il.com, drepper@...hat.com,
microblaze-uclinux@...e.uq.edu.au, grant.likely@...retlab.ca,
linuxppc-dev@...abs.org, vapier.adi@...il.com,
alan@...rguk.ukuu.org.uk, hpa@...or.com,
Michal Simek <monstr@...str.eu>
Subject: Re: [PATCH 01/60] microblaze_v4: Kconfig patches
On Thu, Jun 26, 2008 at 02:29:30PM +0200, monstr@...nam.cz wrote:
> +config HZ
> + int
> + default 100
> +
Consider using kernel/Kconfig.hz instead.
> +config DEFCONFIG_LIST
> + string
> + default "arch/$ARCH/defconfig"
> +
init/Kconfig already has quite a few reasonable defaults for this,
including the case you specify. You can kill this off.
> +source "init/Kconfig"
> +
> +source "arch/microblaze/platform/Kconfig.platform"
> +
> +menu "Processor type and features"
> +
> +config PREEMPT
> + bool "Preemptible Kernel"
> + help
> + This option reduces the latency of the kernel when reacting to
> + real-time or interactive events by allowing a low priority process to
> + be preempted even if it is in kernel mode executing a system call.
> + This allows applications to run more reliably even when the system is
> + under load.
> +
> + Say Y here if you are building a kernel for a desktop, embedded
> + or real-time system. Say N if you are unsure.
> +
kernel/Kconfig.preempt
> +config LARGE_ALLOCS
> + bool "Allow allocating large blocks (> 1MB) of memory"
> + help
> + Allow the slab memory allocator to keep chains for very large
> + memory sizes - up to 32MB. You may need this if your system has
> + a lot of RAM, and you need to able to allocate very large
> + contiguous chunks. If unsure, say N.
> +
Legacy bits, not used anywhere anymore.
> +comment "Boot options"
> +
> +config CMDLINE
> + string "Default kernel command string"
> + default ""
> + help
> + On some architectures there is currently no way for the boot loader
> + to pass arguments to the kernel. For these architectures, you should
> + supply some command-line options at build time by entering them
> + here.
> +
> +config CMDLINE_FORCE
> + bool "Force default kernel command string"
> + help
> + Set this to have arguments from the default kernel command string
> + override those passed by the boot loader.
> +
Consider CMDLINE_BOOL/CMDLINE for consistency with other architectures.
It doesn't make much sense to expose CMDLINE if you don't intend to use
it. Especially when people wonder why their CMDLINE changes are being
clobbered by the boot loader.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists