* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Jamie Lokier @ 2010-07-16 23:49 UTC (permalink / raw)
To: Daniel Walker
Cc: linuxppc-dev, linux-kbuild, Tony Lindgren, Nicolas Pitre,
linux-kernel, linux-arm-kernel, Uwe Kleine-König,
Linus Torvalds, Russell King
In-Reply-To: <1279124563.21162.14.camel@c-dwalke-linux.qualcomm.com>
Daniel Walker wrote:
> > But all the rest is arbitrary and could be part of common shared
> > profiles or the like in defconfig format.
>
> I'm sure most people will want to have a config isolated to their
> specific device. That to me seems reasonable because everyone wants the
> smallest possible kernel they can get for their given device.
Indeed, but people who want the smallest possible kernel for their
specific device _in a particular use context_ tend to want:
- To disable support for parts of the device they aren't using.
For example, an SoC with integrated ethernet that isn't actually
wired up on their board, or where they're using an external ethernet
chip instead for some reason.
- To choose what's modular and what isn't, even for integrated
parts. For example to control the bootup sequence, they might
want to delay integrated USB and IDE initialisation, which is done by
making those modular and loading them after bringing up a splash
screen earlier in the boot scripts.
So there is still a need to be able to override the drivers and
settings, but it's still incredibly useful to have defaults which
describe the SoC or board accurately.
-- Jamie
^ permalink raw reply
* Re: hi, i have two flashs, but my kernel can only find one , how can i write the dts?
From: Grant Likely @ 2010-07-16 21:46 UTC (permalink / raw)
To: hacklu; +Cc: linuxppc-dev
In-Reply-To: <201007161634429622975@gmail.com>
T24gRnJpLCBKdWwgMTYsIDIwMTAgYXQgMjozNCBBTSwgaGFja2x1IDxlbWJlZHdheS50ZXN0QGdt
YWlsLmNvbT4gd3JvdGU6Cj4gdGhpcyBpcyBteSBkdHMgZmlsZToKPiBmbGFzaEAwLDCgewo+IKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoCNhZGRyZXNzLWNlbGxzoD2gPDE+Owo+IKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoCNzaXplLWNlbGxzoD2gPDE+Owo+IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oGNvbXBhdGlibGWgPaAiY2ZpLWZsYXNoIjsKPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBwcm9i
ZS10eXBloD2gIkNGSSI7Cj4goKCgoKCgoKCgoKCgoKCgoKCgIKCgoKCgcmVnoD2gPDCgMKAxMDAw
MDAwPjsKPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBiYW5rLXdpZHRooD2gPDI+Owo+IKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoGRldmljZS13aWR0aKA9oDwxPjsKPiCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKBocmN3QDCgewo+IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgbGFiZWyg
PaAiaHJjdyI7Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKByZWegPaA8MKA0MDAw
MD47Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgfTsKPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKBqZmZzQDQwMDAwoHsKPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoGxhYmVsoD2g
ImpmZnMiOwo+IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgcmVnoD2gPDQwMDAwoDIw
MDAwMD47Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgfTsKPiCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKBqZmZzMkAyNDAwMDCgewo+IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgbGFi
ZWygPaAidWltYWdlIjsKPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoHJlZ6A9oDwy
NDAwMDCgZDgwMDAwPjsKPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKB9Owo+IKCgoKCgoKCgoKCg
oKB9Owo+IGZsYXNoQDEsMKB7Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgI2FkZHJlc3MtY2Vs
bHOgPaA8MT47Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgI3NpemUtY2VsbHOgPaA8MT47Cj4g
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgY29tcGF0aWJsZaA9oCJjZmktZmxhc2giOwo+IKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoHByb2JlLXR5cGWgPaAiQ0ZJIjsKPiCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKByZWegPaA8MTAwMDAwMKAwoDEwMDAwMDA+OwoKVGhpcyBsb29rcyB3cm9uZy4gIElm
IHlvdSdyZSBzZWNvbmQgZmxhc2ggaXMgb24gY2hpcCBzZWxlY3QgMSBhcyB0aGUKbm9kZSBuYW1l
IHN1Z2dlc3RzLCB0aGVuIHRoaXMgc2hvdWxkIGJlIChmaXJzdCBjZWxsIGlzIENTIywgc2Vjb25k
IGlzCm9mZnNldCwgYW5kIHRoaXJkIGlzIHNpemUuICBBbG9zIHlvdSdyZSBtaXNzaW5nIHRoZSAw
eCBwcmVmaXgpOgoKcmVnID0gPDEgMCAweDEwMDAwMDA+OwoKSWYgeW91ciBzZWNvbmQgZmxhc2gg
aXMgb24gY2hpcCBzZWxlY3QgMCB3aXRoIHRoZSBmaXJzdCBmbGFzaCwgYnV0Cm9mZnNldCBieSAw
eDEwMDAwMDAsIHRoZW4gcmVnIHNob3VsZCBiZToKCnJlZyA9IDwwIDB4MTAwMDAwMCAweDEwMDAw
MDA+OwoKYW5kIHRoZSBuYW1lIHNob3VsZCBiZToKCmZsYXNoQDAsMTAwMDAwMCB7IC4uLiB9OwoK
Zy4KCi0tIApHcmFudCBMaWtlbHksIEIuU2MuLCBQLkVuZy4KU2VjcmV0IExhYiBUZWNobm9sb2dp
ZXMgTHRkLgo=
^ permalink raw reply
* Re: [PATCH 1/2] Remove REDWOOD_[456] config options and conditional code
From: David Miller @ 2010-07-16 20:45 UTC (permalink / raw)
To: jwboyer
Cc: randy.dunlap, linuxppc-dev, linux, paulus, john.linn, davidb,
ladis, solomon, vamos-dev, vapier, florian, Artem.Bityutskiy,
qy03fugy, nico, netdev, linux-kernel, miltonm, jkosina, joe,
linux-mtd, dwmw2
In-Reply-To: <20100716142055.GA11736@zod.rchland.ibm.com>
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Fri, 16 Jul 2010 10:20:55 -0400
> On Fri, Jul 16, 2010 at 02:29:02PM +0200, Christian Dietrich wrote:
>>The config options for REDWOOD_[456] were commented out in the powerpc
>>Kconfig. The ifdefs referencing this options therefore are dead and all
>>references to this can be removed (Also dependencies in other KConfig
>>files).
>>
>>Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
>>Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
>
> This seems fine with me.
>
> The only question is which tree it coms through. I'm happy to take it
> in via mine if the netdev and MTD people are fine with that. Otherwise,
> my ack is below.
>
> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Please take it:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Catalin Marinas @ 2010-07-16 20:44 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
linux-kbuild, Tony Lindgren, Nicolas Pitre, lkml, linuxppc-dev,
Uwe Kleine-König, Linus Torvalds, linux-arm-kernel
In-Reply-To: <AANLkTimKpmZaGRYfYs8HGDz-_VG8ePXN6bZvl2-YcNdR@mail.gmail.com>
On Fri, 2010-07-16 at 21:17 +0100, Grant Likely wrote:
> On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
> >> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >> >
> >> > DOH.
> >>
> >> Well, it's possible that the correct approach is a mixture.
> >>
> >> Automatically do the trivial cases (recursive selects, dependencies
> >> that are simple or of the form "x && y" etc), and warn about the cases
> >> that aren't trivial (where "not trivial" may not necessarily be about
> >> fundamentally ambiguous ones, but just "complex enough that I won't
> >> even try").
> >
> > There is still a risk with this approach when the Kconfig isn't entirely
> > correct. For example, on ARM we have (I pushed a patch already):
> >
> > config CPU_32v6K
> > depends on CPU_V6
> >
> > config CPU_V7
> > select CPU_32v6K
> >
> > In this simple approach, we end up selecting CPU_V6 when we only need
> > CPU_V7. There other places like this in the kernel.
> >
> > Of course, kbuild could still warn but if people rely on this feature to
> > select options automatically I suspect they would ignore the warnings.
>
> In my first patch, I made Kconfig problems errors instead of warnings.
> That would prevent people from ignoring them.
My point was that if we allow kbuild to select dependencies
automatically (as per Nico's initial suggestion, followed up by Linus),
in the above situation CPU_V7 would trigger the selection of CPU_V6 and
I don't want this. If we rely on such automatic selection of the
"depends on" options, we can't make the warnings be errors.
--
Catalin
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-16 20:37 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
linux-kbuild, Tony Lindgren, Catalin Marinas, linuxppc-dev, lkml,
Uwe Kleine-König, Linus Torvalds, linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1007161629270.10598@xanadu.home>
On Fri, Jul 16, 2010 at 2:29 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 16 Jul 2010, Grant Likely wrote:
>
>> On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>> > On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
>> >> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <nico@fluxnic.net> wr=
ote:
>> >> >
>> >> > DOH.
>> >>
>> >> Well, it's possible that the correct approach is a mixture.
>> >>
>> >> Automatically do the trivial cases (recursive selects, dependencies
>> >> that are simple or of the form "x && y" etc), and warn about the case=
s
>> >> that aren't trivial (where "not trivial" may not necessarily be about
>> >> fundamentally ambiguous ones, but just "complex enough that I won't
>> >> even try").
>> >
>> > There is still a risk with this approach when the Kconfig isn't entire=
ly
>> > correct. For example, on ARM we have (I pushed a patch already):
>> >
>> > config CPU_32v6K
>> > =A0 =A0 =A0 =A0depends on CPU_V6
>> >
>> > config CPU_V7
>> > =A0 =A0 =A0 =A0select CPU_32v6K
>> >
>> > In this simple approach, we end up selecting CPU_V6 when we only need
>> > CPU_V7. There other places like this in the kernel.
>> >
>> > Of course, kbuild could still warn but if people rely on this feature =
to
>> > select options automatically I suspect they would ignore the warnings.
>>
>> In my first patch, I made Kconfig problems errors instead of warnings.
>> =A0That would prevent people from ignoring them.
>
> ACK.
It would also flush out any current Kconfig dependency issues.
g.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Nicolas Pitre @ 2010-07-16 20:29 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
linux-kbuild, Tony Lindgren, Catalin Marinas, linuxppc-dev, lkml,
Uwe Kleine-König, Linus Torvalds, linux-arm-kernel
In-Reply-To: <AANLkTimKpmZaGRYfYs8HGDz-_VG8ePXN6bZvl2-YcNdR@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1361 bytes --]
On Fri, 16 Jul 2010, Grant Likely wrote:
> On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
> >> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >> >
> >> > DOH.
> >>
> >> Well, it's possible that the correct approach is a mixture.
> >>
> >> Automatically do the trivial cases (recursive selects, dependencies
> >> that are simple or of the form "x && y" etc), and warn about the cases
> >> that aren't trivial (where "not trivial" may not necessarily be about
> >> fundamentally ambiguous ones, but just "complex enough that I won't
> >> even try").
> >
> > There is still a risk with this approach when the Kconfig isn't entirely
> > correct. For example, on ARM we have (I pushed a patch already):
> >
> > config CPU_32v6K
> > depends on CPU_V6
> >
> > config CPU_V7
> > select CPU_32v6K
> >
> > In this simple approach, we end up selecting CPU_V6 when we only need
> > CPU_V7. There other places like this in the kernel.
> >
> > Of course, kbuild could still warn but if people rely on this feature to
> > select options automatically I suspect they would ignore the warnings.
>
> In my first patch, I made Kconfig problems errors instead of warnings.
> That would prevent people from ignoring them.
ACK.
Nicolas
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-16 20:17 UTC (permalink / raw)
To: Catalin Marinas
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
linux-kbuild, Tony Lindgren, Nicolas Pitre, lkml, linuxppc-dev,
Uwe Kleine-König, Linus Torvalds, linux-arm-kernel
In-Reply-To: <1279310976.18579.8.camel@e102109-lin.cambridge.arm.com>
On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
>> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <nico@fluxnic.net> wrote=
:
>> >
>> > DOH.
>>
>> Well, it's possible that the correct approach is a mixture.
>>
>> Automatically do the trivial cases (recursive selects, dependencies
>> that are simple or of the form "x && y" etc), and warn about the cases
>> that aren't trivial (where "not trivial" may not necessarily be about
>> fundamentally ambiguous ones, but just "complex enough that I won't
>> even try").
>
> There is still a risk with this approach when the Kconfig isn't entirely
> correct. For example, on ARM we have (I pushed a patch already):
>
> config CPU_32v6K
> =A0 =A0 =A0 =A0depends on CPU_V6
>
> config CPU_V7
> =A0 =A0 =A0 =A0select CPU_32v6K
>
> In this simple approach, we end up selecting CPU_V6 when we only need
> CPU_V7. There other places like this in the kernel.
>
> Of course, kbuild could still warn but if people rely on this feature to
> select options automatically I suspect they would ignore the warnings.
In my first patch, I made Kconfig problems errors instead of warnings.
That would prevent people from ignoring them.
g.
^ permalink raw reply
* Re: [PATCH v2] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers
From: Scott Wood @ 2010-07-16 20:12 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Peter Tyser, linux-kernel, Dave Jiang, linuxppc-dev,
Doug Thompson, Andrew Morton
In-Reply-To: <20100715182507.GA3482@oksana.dev.rtsoft.ru>
On Thu, 15 Jul 2010 22:25:07 +0400
Anton Vorontsov <avorontsov@mvista.com> wrote:
> Simply add proper IDs into the device table.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
>
> It appears that the driver has two device ID tables. :-)
> So, my previous attempt enabled only half of the functionality.
>
> Andrew,
>
> Can you please replace
>
> edac-mpc85xx-add-support-for-mpc8569-edac-controllers.patch
>
> with this patch? It also adds some more IDs for the newer chips.
>
> Thanks!
>
> drivers/edac/mpc85xx_edac.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index 52ca09b..3820879 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -646,8 +646,12 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
> { .compatible = "fsl,mpc8555-l2-cache-controller", },
> { .compatible = "fsl,mpc8560-l2-cache-controller", },
> { .compatible = "fsl,mpc8568-l2-cache-controller", },
> + { .compatible = "fsl,mpc8569-l2-cache-controller", },
> { .compatible = "fsl,mpc8572-l2-cache-controller", },
> + { .compatible = "fsl,p1020-l2-cache-controller", },
> + { .compatible = "fsl,p1021-l2-cache-controller", },
> { .compatible = "fsl,p2020-l2-cache-controller", },
> + { .compatible = "fsl,p4080-l2-cache-controller", },
L2 on the p4080 is quite different from those other chips. It's part
of the core, controlled by SPRs.
-Scott
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Arnd Bergmann @ 2010-07-16 20:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
Nicolas Pitre, Tony Lindgren, Catalin Marinas, linux-kbuild, lkml,
Uwe Kleine-König, linuxppc-dev, linux-arm-kernel
In-Reply-To: <AANLkTikqHnyFVJF0Pzwy2xtKeNSXYAPFdPkAkLiXK8Ls@mail.gmail.com>
On Friday 16 July 2010 20:46:17 Linus Torvalds wrote:
> Maybe a full "solver" is unnecessary, for example, but just a simple
> "automatically enable the direct dependencies and scream when it's not
> simple any more" would take care of 99% of the common cases, and then
> warn when it needs some manual help.
I think the recursion should also be limited to cases where the
dependency is a valid selectable option, i.e. not for
# this architecture does not support MMIO
config HAS_IOMEM
def_bool 'n'
config PCI
bool "PCI Device drivers"
depends on HAS_IOMEM
config FOO
tristate "Some device driver"
depends on PCI
In this case, it would be straightforward for the solver to enable PCI
for when something selects CONFIG_FOO, but it should print a warning
if this is attempted while HAS_IOMEM is unconditionally disabled,
since that puts it into the "not simple" category.
Arnd
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Catalin Marinas @ 2010-07-16 20:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
linux-kbuild, Tony Lindgren, Nicolas Pitre, lkml,
Uwe Kleine-König, linuxppc-dev, linux-arm-kernel
In-Reply-To: <AANLkTikqHnyFVJF0Pzwy2xtKeNSXYAPFdPkAkLiXK8Ls@mail.gmail.com>
On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >
> > DOH.
>
> Well, it's possible that the correct approach is a mixture.
>
> Automatically do the trivial cases (recursive selects, dependencies
> that are simple or of the form "x && y" etc), and warn about the cases
> that aren't trivial (where "not trivial" may not necessarily be about
> fundamentally ambiguous ones, but just "complex enough that I won't
> even try").
There is still a risk with this approach when the Kconfig isn't entirely
correct. For example, on ARM we have (I pushed a patch already):
config CPU_32v6K
depends on CPU_V6
config CPU_V7
select CPU_32v6K
In this simple approach, we end up selecting CPU_V6 when we only need
CPU_V7. There other places like this in the kernel.
Of course, kbuild could still warn but if people rely on this feature to
select options automatically I suspect they would ignore the warnings.
--
Catalin
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Arnd Bergmann @ 2010-07-16 20:01 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Nicolas Pitre, linux-kernel, Linus Torvalds,
Russell King, Uwe Kleine-König, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <AANLkTinyFBTKYaryFANYheTuP-biJUws2x01NRNZPb4M@mail.gmail.com>
On Friday 16 July 2010 19:57:55 Grant Likely wrote:
> On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
>
> sfr and I were talking about your patch the other day. Just warning
> on incomplete dependencies is enough to make it actually workable for
> me (without my ugly post-processing step). I was very happy to hear
> that it is in linux-next.
>
> Last missing piece is being able to do "select FOO = n", which Stephen
> is currently working on.
Are there a lot of symbols for which this is needed? If there is only
a handful, you could work around this by selectively adding
config FOO
bool "foo"
default !FOO_DISABLE
config FOO_DISABLE
def_bool "n"
Arnd
^ permalink raw reply
* Re: Badness with the kernel version 2.6.35-rc1-git1 running on P6 box
From: David Rientjes @ 2010-07-16 19:19 UTC (permalink / raw)
To: Dave Hansen
Cc: sachinp, Eric Dumazet, LKML, linuxppc-dev, Jan-Bernd Themann,
netdev, David Miller, divya
In-Reply-To: <1279301731.9207.239.camel@nimitz>
On Fri, 16 Jul 2010, Dave Hansen wrote:
> > > SLUB: Unable to allocate memory on node -1 (gfp=0x20)
> > > cache: kmalloc-16384, object size: 16384, buffer size: 16384,
> > default order: 2, min order: 0
> > > node 0: slabs: 28, objs: 292, free: 0
> > > ip: page allocation failure. order:0, mode:0x8020
> > > Call Trace:
> > > [c000000006a0eb40] [c000000000011c30] .show_stack+0x6c/0x16c (unreliable)
> > > [c000000006a0ebf0] [c00000000012129c] .__alloc_pages_nodemask+0x6a0/0x75c
> > > [c000000006a0ed70] [c0000000001527cc] .alloc_pages_current+0xc4/0x104
> > > [c000000006a0ee10] [c00000000011fca4] .__get_free_pages+0x18/0x90
> > > [c000000006a0ee90] [c0000000004f7058] .ehea_get_stats+0x4c/0x1bc
> > > [c000000006a0ef30] [c0000000005a0a04] .dev_get_stats+0x38/0x64
> > > [c000000006a0efc0] [c0000000005b456c] .rtnl_fill_ifinfo+0x35c/0x85c
> > > [c000000006a0f150] [c0000000005b5920] .rtmsg_ifinfo+0x164/0x204
> > > [c000000006a0f210] [c0000000005a6d6c] .dev_change_flags+0x4c/0x7c
> > > [c000000006a0f2a0] [c0000000005b50b4] .do_setlink+0x31c/0x750
> > > [c000000006a0f3b0] [c0000000005b6724] .rtnl_newlink+0x388/0x618
> > > [c000000006a0f5f0] [c0000000005b6350] .rtnetlink_rcv_msg+0x268/0x2b4
> > > [c000000006a0f6a0] [c0000000005cfdc0] .netlink_rcv_skb+0x74/0x108
> > > [c000000006a0f730] [c0000000005b60c4] .rtnetlink_rcv+0x38/0x5c
> > > [c000000006a0f7c0] [c0000000005cf8c8] .netlink_unicast+0x318/0x3f4
> > > [c000000006a0f890] [c0000000005d05b4] .netlink_sendmsg+0x2d0/0x310
> > > [c000000006a0f970] [c00000000058e1e8] .sock_sendmsg+0xd4/0x110
> > > [c000000006a0fb50] [c00000000058e514] .SyS_sendmsg+0x1f4/0x288
> > > [c000000006a0fd70] [c00000000058c2b8] .SyS_socketcall+0x214/0x280
> > > [c000000006a0fe30] [c0000000000085b4] syscall_exit+0x0/0x40
> > > Mem-Info:
> > > Node 0 DMA per-cpu:
> > > CPU 0: hi: 0, btch: 1 usd: 0
> > > CPU 1: hi: 0, btch: 1 usd: 0
> > > CPU 2: hi: 0, btch: 1 usd: 0
> > > CPU 3: hi: 0, btch: 1 usd: 0
> > >
> > > The mainline 2.6.35-rc5 worked fine.
> >
> > Maybe you were lucky with 2.6.35-rc5
> >
> > Anyway ehea should not use GFP_ATOMIC in its ehea_get_stats() method,
> > called in process context, but GFP_KERNEL.
> >
> > Another patch is needed for ehea_refill_rq_def() as well.
>
> You're right that this is abusing GFP_ATOMIC.
>
> But is, this is just a normal "GFP_ATOMIC" allocation failure? "SLUB:
> Unable to allocate memory on node -1" seems like a somewhat
> inappropriate error message for that.
>
The slub message is seperate and doesn't generate a call trace, even
though it is a (minimum) order-0 GFP_ATOMIC allocation as well. The page
allocation failure is seperate instance that is calling the page
allocator, not the slab allocator.
> It isn't immediately obvious where the -1 is coming from. Does it truly
> mean "allocate from any node" here, or is that a buglet in and of
> itself?
>
Yes, slub uses -1 to indicate that the allocation need not come from a
specific node.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-16 18:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Nicolas Pitre, linux-kernel, Linus Torvalds,
Uwe Kleine-König, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20100716183028.GB26854@n2100.arm.linux.org.uk>
On Fri, Jul 16, 2010 at 12:30 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
>> For example, if I want CONFIG_MTD_CMDLINE_PARTS=3Dy, the system may be
>> smart enough to notice and automatically enable CONFIG_MTD and
>> CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
>
> How do you sort out something like this:
>
> config FOO
> =A0 =A0 =A0 =A0bool "Foo"
> =A0 =A0 =A0 =A0depends on (A && B) || C
>
> Do you enable A and B, A, B and C or just C?
>
> Bear in mind that A could be 'X86', 'M68K' or any other arch specific
> symbol.
>
> I prefer the warning method because it prompts you to investigate what's
> changed and sort out the problem by ensuring that the appropriate symbols
> are also selected. =A0The automatic selection of dependencies method carr=
ies
> the risk that it'll do the wrong thing with the above scenario.
Good point.
g.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Linus Torvalds @ 2010-07-16 18:46 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
linux-kbuild, Tony Lindgren, Catalin Marinas,
Uwe Kleine-König, lkml, linuxppc-dev, linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1007161439240.10598@xanadu.home>
On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> DOH.
Well, it's possible that the correct approach is a mixture.
Automatically do the trivial cases (recursive selects, dependencies
that are simple or of the form "x && y" etc), and warn about the cases
that aren't trivial (where "not trivial" may not necessarily be about
fundamentally ambiguous ones, but just "complex enough that I won't
even try").
Maybe a full "solver" is unnecessary, for example, but just a simple
"automatically enable the direct dependencies and scream when it's not
simple any more" would take care of 99% of the common cases, and then
warn when it needs some manual help.
So it's not a strict "one or the other" issue. The solution could be
"some of both".
Linus
^ permalink raw reply
* Re: [PATCH 1/5] v2 Split the memory_block structure
From: Dave Hansen @ 2010-07-16 18:45 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linux-mm, linux-kernel, KAMEZAWA Hiroyuki, linuxppc-dev
In-Reply-To: <4C40A3BC.3060504@austin.ibm.com>
On Fri, 2010-07-16 at 13:23 -0500, Nathan Fontenot wrote:
> >> - if (mem->state != from_state_req) {
> >> - ret = -EINVAL;
> >> - goto out;
> >> + list_for_each_entry(mbs, &mem->sections, next) {
> >> + if (mbs->state != from_state_req)
> >> + continue;
> >> +
> >> + ret = memory_block_action(mbs, to_state);
> >> + if (ret)
> >> + break;
> >> + }
> >> +
> >> + if (ret) {
> >> + list_for_each_entry(mbs, &mem->sections, next) {
> >> + if (mbs->state == from_state_req)
> >> + continue;
> >> +
> >> + if (memory_block_action(mbs, to_state))
> >> + printk(KERN_ERR "Could not re-enable memory "
> >> + "section %lx\n", mbs->phys_index);
> >> + }
> >> }
> >
> > Please just use a goto here. It's nicer looking, and much more in line
> > with what's there already.
>
> Not sure if I follow on where you want the goto. If you mean after the
> if (memory_block_action())... I purposely did not have a goto here.
> Since this is in the recovery path I wanted to make sure we tried to return
> every memory section to the original state.
Looking at it a little closer, I see what you're doing now.
First of all, should memory_block_action() get a new name since it isn
not taking 'memory_block_section's?
The thing I would have liked to see is to have that error handling block
out of the way a bit. But, the function is small, and there's not _too_
much code in there, so what you have is probably the best way to do it.
Minor nit: Please pull the memory_block_action() out of the if() and do
the:
> >> + ret = memory_block_action(mbs, to_state);
> >> + if (ret)
> >> + break;
thing like above. It makes it much more obvious that the loop is
related to the top one. I was thinking if it made sense to have a
helper function to go through and do that list walk, so you could do:
ret = set_all_states(mem->sections, to_state);
if (ret)
set_all_states(mem->sections, old_state);
But I think you'd need to pass in a bit more information, so it probably
isn't worth doing that, either.
-- Dave
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Nicolas Pitre @ 2010-07-16 18:40 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Uwe Kleine-König, lkml, Linus Torvalds,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20100716183028.GB26854@n2100.arm.linux.org.uk>
On Fri, 16 Jul 2010, Russell King - ARM Linux wrote:
> On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
> > For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
> > smart enough to notice and automatically enable CONFIG_MTD and
> > CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
>
> How do you sort out something like this:
>
> config FOO
> bool "Foo"
> depends on (A && B) || C
DOH.
Nicolas
^ permalink raw reply
* Re: [PATCH 1/5] v2 Split the memory_block structure
From: Dave Hansen @ 2010-07-16 18:33 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linux-mm, linux-kernel, KAMEZAWA Hiroyuki, linuxppc-dev
In-Reply-To: <4C40A3BC.3060504@austin.ibm.com>
On Fri, 2010-07-16 at 13:23 -0500, Nathan Fontenot wrote:
> > If the memory_block's state was inferred to be the same as each
> > memory_block_section, couldn't we just keep a start and end phys_index
> > in the memory_block, and get away from having memory_block_sections at
> > all?
>
> Oooohhh... I like. Looking at the code it appears this is possible. I'll
> try this out and include it in the next version of the patch.
>
> Do you think we need to add an additional file to each memory block directory
> to indicate the number of memory sections in the memory block that are actually
> present?
I think it's easiest to just say that each 'memory_block' can only hold
contiguous 'memory_block_sections', and we give either the start/end or
start/length pairs. It gets a lot more complicated if we have to deal
with lots of holes.
I can just see the hardware designers reading this thread, with their
Dr. Evil laughs trying to come up with a reason to give us a couple of
terabytes of RAM with only every-other 16MB area populated. :)
-- Dave
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Nicolas Pitre @ 2010-07-16 18:31 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Uwe Kleine-König, linux-kernel,
Linus Torvalds, Russell King, linuxppc-dev, linux-arm-kernel
In-Reply-To: <AANLkTilY0rvbp7brGsnyuGhPjFvpVYInNWlAlf5tT4zG@mail.gmail.com>
On Fri, 16 Jul 2010, Grant Likely wrote:
> On Fri, Jul 16, 2010 at 12:19 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
> > smart enough to notice and automatically enable CONFIG_MTD and
> > CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
>
> I fully agree. However, the warnings make the system work now while
> we wait for a full solver to be implemented.
Why can't the tool just _select_ the option it is warning about when a
dependency is not met? That shouldn't require a full solver.
Nicolas
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Russell King - ARM Linux @ 2010-07-16 18:30 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Uwe Kleine-König, linux-kernel,
Linus Torvalds, linuxppc-dev, linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1007161406120.10598@xanadu.home>
On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
> For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
> smart enough to notice and automatically enable CONFIG_MTD and
> CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
How do you sort out something like this:
config FOO
bool "Foo"
depends on (A && B) || C
Do you enable A and B, A, B and C or just C?
Bear in mind that A could be 'X86', 'M68K' or any other arch specific
symbol.
I prefer the warning method because it prompts you to investigate what's
changed and sort out the problem by ensuring that the appropriate symbols
are also selected. The automatic selection of dependencies method carries
the risk that it'll do the wrong thing with the above scenario.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Russell King - ARM Linux @ 2010-07-16 18:07 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Nicolas Pitre, linux-kernel, Linus Torvalds,
Uwe Kleine-König, linuxppc-dev, linux-arm-kernel
In-Reply-To: <AANLkTinyFBTKYaryFANYheTuP-biJUws2x01NRNZPb4M@mail.gmail.com>
On Fri, Jul 16, 2010 at 11:57:55AM -0600, Grant Likely wrote:
> Last missing piece is being able to do "select FOO = n", which Stephen
> is currently working on.
I thought Linus' idea was to use:
KBUILD_KCONFIG=file make allnoconfig
in which case any option which would be presented to the user which hasn't
been selected by 'file' ends up being set to n. That means there's no
need for a special "select FOO=n" construct.
See one of Linus' replies on June 3:
Message-ID: <alpine.LFD.2.00.1006031317410.8175@i5.linux-foundation.org>
^ permalink raw reply
* Re: [PATCH 1/5] v2 Split the memory_block structure
From: Nathan Fontenot @ 2010-07-16 18:23 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-mm, linux-kernel, KAMEZAWA Hiroyuki, linuxppc-dev
In-Reply-To: <1279300521.9207.222.camel@nimitz>
On 07/16/2010 12:15 PM, Dave Hansen wrote:
> On Thu, 2010-07-15 at 13:37 -0500, Nathan Fontenot wrote:
>> @@ -123,13 +130,20 @@
>> static ssize_t show_mem_removable(struct sys_device *dev,
>> struct sysdev_attribute *attr, char *buf)
>> {
>> + struct memory_block *mem;
>> + struct memory_block_section *mbs;
>> unsigned long start_pfn;
>> - int ret;
>> - struct memory_block *mem =
>> - container_of(dev, struct memory_block, sysdev);
>> + int ret = 1;
>> +
>> + mem = container_of(dev, struct memory_block, sysdev);
>> + mutex_lock(&mem->state_mutex);
>>
>> - start_pfn = section_nr_to_pfn(mem->phys_index);
>> - ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> + list_for_each_entry(mbs, &mem->sections, next) {
>> + start_pfn = section_nr_to_pfn(mbs->phys_index);
>> + ret &= is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> + }
>> +
>> + mutex_unlock(&mem->state_mutex);
>> return sprintf(buf, "%d\n", ret);
>> }
>
> Now that the "state_mutex" is getting used for other stuff, should we
> just make it "mutex"?
>
>> @@ -182,16 +196,16 @@
>> * OK to have direct references to sparsemem variables in here.
>> */
>> static int
>> -memory_block_action(struct memory_block *mem, unsigned long action)
>> +memory_block_action(struct memory_block_section *mbs, unsigned long action)
>> {
>> int i;
>> unsigned long psection;
>> unsigned long start_pfn, start_paddr;
>> struct page *first_page;
>> int ret;
>> - int old_state = mem->state;
>> + int old_state = mbs->state;
>>
>> - psection = mem->phys_index;
>> + psection = mbs->phys_index;
>> first_page = pfn_to_page(psection << PFN_SECTION_SHIFT);
>>
>> /*
>> @@ -217,18 +231,18 @@
>> ret = online_pages(start_pfn, PAGES_PER_SECTION);
>> break;
>> case MEM_OFFLINE:
>> - mem->state = MEM_GOING_OFFLINE;
>> + mbs->state = MEM_GOING_OFFLINE;
>> start_paddr = page_to_pfn(first_page) << PAGE_SHIFT;
>> ret = remove_memory(start_paddr,
>> PAGES_PER_SECTION << PAGE_SHIFT);
>> if (ret) {
>> - mem->state = old_state;
>> + mbs->state = old_state;
>> break;
>> }
>> break;
>> default:
>> WARN(1, KERN_WARNING "%s(%p, %ld) unknown action: %ld\n",
>> - __func__, mem, action, action);
>> + __func__, mbs, action, action);
>> ret = -EINVAL;
>> }
>>
>> @@ -238,19 +252,34 @@
>> static int memory_block_change_state(struct memory_block *mem,
>> unsigned long to_state, unsigned long from_state_req)
>> {
>> + struct memory_block_section *mbs;
>> int ret = 0;
>> +
>> mutex_lock(&mem->state_mutex);
>>
>> - if (mem->state != from_state_req) {
>> - ret = -EINVAL;
>> - goto out;
>> + list_for_each_entry(mbs, &mem->sections, next) {
>> + if (mbs->state != from_state_req)
>> + continue;
>> +
>> + ret = memory_block_action(mbs, to_state);
>> + if (ret)
>> + break;
>> + }
>> +
>> + if (ret) {
>> + list_for_each_entry(mbs, &mem->sections, next) {
>> + if (mbs->state == from_state_req)
>> + continue;
>> +
>> + if (memory_block_action(mbs, to_state))
>> + printk(KERN_ERR "Could not re-enable memory "
>> + "section %lx\n", mbs->phys_index);
>> + }
>> }
>
> Please just use a goto here. It's nicer looking, and much more in line
> with what's there already.
Not sure if I follow on where you want the goto. If you mean after the
if (memory_block_action())... I purposely did not have a goto here.
Since this is in the recovery path I wanted to make sure we tried to return
every memory section to the original state.
>
> ...
>> ===================================================================
>> --- linux-2.6.orig/include/linux/memory.h 2010-07-15 08:48:41.000000000 -0500
>> +++ linux-2.6/include/linux/memory.h 2010-07-15 09:54:06.000000000 -0500
>> @@ -19,9 +19,15 @@
>> #include <linux/node.h>
>> #include <linux/compiler.h>
>> #include <linux/mutex.h>
>> +#include <linux/list.h>
>>
>> -struct memory_block {
>> +struct memory_block_section {
>> + unsigned long state;
>> unsigned long phys_index;
>> + struct list_head next;
>> +};
>> +
>> +struct memory_block {
>> unsigned long state;
>> /*
>> * This serializes all state change requests. It isn't
>> @@ -34,6 +40,7 @@
>> void *hw; /* optional pointer to fw/hw data */
>> int (*phys_callback)(struct memory_block *);
>> struct sys_device sysdev;
>> + struct list_head sections;
>> };
>
> It looks like we have state in both the memory_block and
> memory_block_section. That seems a bit confusing to me. This also
> looks like it would permit non-contiguous memory_block_sections in a
> memory_block. Is that what you intended?
The two state fields are a bit confusing, perhaps slightly different
names, block_state and section_state. The reason for two state fileds
is that memory online/offline is done on a memory block and an entire
memory block is considered online or offline. The state field in the
memory_block_section is used to track the state of each of the memory
sections as you work through onlining or offlining the entire block
so that if an error occurs we can return each memory section to its
original state.
You're correct that there is nothing that prevents non-contiguous memory
sections in a memory block. It was not my intention to have this, but
looking at the patches there is nothing to prevent it.
>
> If the memory_block's state was inferred to be the same as each
> memory_block_section, couldn't we just keep a start and end phys_index
> in the memory_block, and get away from having memory_block_sections at
> all?
Oooohhh... I like. Looking at the code it appears this is possible. I'll
try this out and include it in the next version of the patch.
Do you think we need to add an additional file to each memory block directory
to indicate the number of memory sections in the memory block that are actually
present?
-Nathan
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-16 18:21 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Uwe Kleine-König, linux-kernel,
Linus Torvalds, Russell King, linuxppc-dev, linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1007161406120.10598@xanadu.home>
On Fri, Jul 16, 2010 at 12:19 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 16 Jul 2010, Grant Likely wrote:
>
>> On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>> > On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
>> >> - It still doesn't resolve dependencies. =A0A solver would help with =
this.
>> >> =A0 For the time being I work around the problem by running the gener=
ated
>> >> =A0 config through 'oldconfig' and looking for differences. =A0If the=
files
>> >> =A0 differ (ignoring comments and generateconfig_* options) after old=
config,
>> >> =A0 then the <board>_defconfig target returns a failure. =A0(but leav=
es the
>> >> =A0 new .config intact so the user can resolve it with menuconfig). =
=A0This
>> >> =A0 way at least the user is told when a Kconfig fragment is invalid.
>> >
>> > It's not a solver but I'm pushing a patch to warn on selecting symbols
>> > with unmet dependencies so that you can select further symbols (manual
>> > solving). The patch is in linux-next but you also can grab it from:
>> >
>> > http://git.kernel.org/?p=3Dlinux/kernel/git/cmarinas/linux-2.6-cm.git;=
a=3Dcommitdiff_plain;h=3D5d87db2d2a332784bbf2b1ec3e141486f4d41d6f
>>
>> sfr and I were talking about your patch the other day. =A0Just warning
>> on incomplete dependencies is enough to make it actually workable for
>> me (without my ugly post-processing step). =A0I was very happy to hear
>> that it is in linux-next.
>>
>> Last missing piece is being able to do "select FOO =3D n", which Stephen
>> is currently working on.
>
> Instead of (or in addition to) warning for incomplete
> dependencies, I'd much prefer if the prerequisites were recursively
> selected automatically. =A0This way if some options are moved inside a
> submenu at some point with a config symbol for that subcategory
> (e.g. CONFIG_NETDEV_1000), or if the subsystem is reorganized into
> submodules that are required for some driver to work, then my
> config will still be fine.
>
> For example, if I want CONFIG_MTD_CMDLINE_PARTS=3Dy, the system may be
> smart enough to notice and automatically enable CONFIG_MTD and
> CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
I fully agree. However, the warnings make the system work now while
we wait for a full solver to be implemented.
g.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Nicolas Pitre @ 2010-07-16 18:19 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Uwe Kleine-König, linux-kernel,
Linus Torvalds, Russell King, linuxppc-dev, linux-arm-kernel
In-Reply-To: <AANLkTinyFBTKYaryFANYheTuP-biJUws2x01NRNZPb4M@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2072 bytes --]
On Fri, 16 Jul 2010, Grant Likely wrote:
> On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
> >> - It still doesn't resolve dependencies. A solver would help with this.
> >> For the time being I work around the problem by running the generated
> >> config through 'oldconfig' and looking for differences. If the files
> >> differ (ignoring comments and generateconfig_* options) after oldconfig,
> >> then the <board>_defconfig target returns a failure. (but leaves the
> >> new .config intact so the user can resolve it with menuconfig). This
> >> way at least the user is told when a Kconfig fragment is invalid.
> >
> > It's not a solver but I'm pushing a patch to warn on selecting symbols
> > with unmet dependencies so that you can select further symbols (manual
> > solving). The patch is in linux-next but you also can grab it from:
> >
> > http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f
>
> sfr and I were talking about your patch the other day. Just warning
> on incomplete dependencies is enough to make it actually workable for
> me (without my ugly post-processing step). I was very happy to hear
> that it is in linux-next.
>
> Last missing piece is being able to do "select FOO = n", which Stephen
> is currently working on.
Instead of (or in addition to) warning for incomplete
dependencies, I'd much prefer if the prerequisites were recursively
selected automatically. This way if some options are moved inside a
submenu at some point with a config symbol for that subcategory
(e.g. CONFIG_NETDEV_1000), or if the subsystem is reorganized into
submodules that are required for some driver to work, then my
config will still be fine.
For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
smart enough to notice and automatically enable CONFIG_MTD and
CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
Nicolas
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-16 18:18 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Nicolas Pitre, linux-kernel, Linus Torvalds,
Uwe Kleine-König, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20100716180701.GA26854@n2100.arm.linux.org.uk>
On Fri, Jul 16, 2010 at 12:07 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jul 16, 2010 at 11:57:55AM -0600, Grant Likely wrote:
>> Last missing piece is being able to do "select FOO =3D n", which Stephen
>> is currently working on.
>
> I thought Linus' idea was to use:
>
> KBUILD_KCONFIG=3Dfile make allnoconfig
That was more a prototype of the idea; but it's a pretty cumbersome
user interface. :-) By changing the makefile to look for kconfig
fragments in the configs directory, the user interface for choosing a
config remains exactly the same.
As for the allnoconfig bit....
> in which case any option which would be presented to the user which hasn'=
t
> been selected by 'file' ends up being set to n. =A0That means there's no
> need for a special "select FOO=3Dn" construct.
...Linus chimed in on this that he doesn't actually care much. I
think defconfig with an empty initial config file makes a lot more
sense than allnoconfig so that we're using the default values from the
normal Kconfig files.
> See one of Linus' replies on June 3:
> Message-ID: <alpine.LFD.2.00.1006031317410.8175@i5.linux-foundation.org>
See this response:
Message-ID: <AANLkTik-QCXFnjma3J28B9h27uajOcDhthTGz99zKgVi@mail.gmail.com>
http://news.gmane.org/find-root.php?message_id=3D%3cAANLkTik%2dQCXFnjma3J28=
B9h27uajOcDhthTGz99zKgVi%40mail.gmail.com%3e
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Linus Torvalds @ 2010-07-16 18:17 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stephen Rothwell, Daniel Walker, linux-kbuild, Tony Lindgren,
Catalin Marinas, Nicolas Pitre, linux-kernel,
Uwe Kleine-König, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20100716180701.GA26854@n2100.arm.linux.org.uk>
On Fri, Jul 16, 2010 at 11:07 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> I thought Linus' idea was to use:
>
> KBUILD_KCONFIG=file make allnoconfig
See an earlier reply - that is indeed what I suggested, and yes, it
avoids the need to be able to "unselect" things.
However, it turns out that even then you do want to extend the Kconfig
language with the ability to select particular values. Not for boolean
(or even tristate things), but for things that select an integer or
string value etc.
So the "select OPTION=xyz" syntax ends up being a good thing even for
the "-n" (allnoconfig) case too.
And while I think the allnoconfig model has some advantages (the
Kconfig input file ends up being independent of the default values),
that very fact ends up being a disadvantage too (the Kconfig input
file likely ends up being larger, since _hopefully_ the defaults are
sane).
So I'm not at all married to the "allnoconfig" model. It's one way of
doing things, but I think the argument that we should start with the
defaults and modify those instead is not an invalid one.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox