* Re: ARM defconfig files [not found] <20100603074548.GA12104@flint.arm.linux.org.uk> @ 2010-06-03 14:48 ` Linus Torvalds 2010-06-03 16:46 ` Tony Lindgren ` (2 more replies) 0 siblings, 3 replies; 133+ messages in thread From: Linus Torvalds @ 2010-06-03 14:48 UTC (permalink / raw) To: Russell King Cc: Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm [ Continuation on the "ARM MSM updates" thread ] On Thu, 3 Jun 2010, Russell King wrote: > > It'd be nice if you'd copy me... Yeah, the thread started out as a "I got really bored with lots of msm patches", and then just expanded into what I think is wrong with the sub-architectures. > On the defconfig files, you may not like them - I don't like the > proliferation of them either. What I've always wanted to see is > one defconfig per class of machines - in other words, one mach-XXX. I can understand that, but at the same time, I do think that the "defconfig" file concept as it is now is just broken. To the point of being unfixable. It's obviously just a copy of the final .config, and it's fundamentally not really readable (and especially not writable) by humans. And that all actually made some sense way-back-when, back when it was originally done - back when our config files were tiny (compared to what they are now), and when it ended up being the default input for the config. It just doesn't make much sense any more. The Kconfig files themselves end up having defaults for the core things, and the non-core things are too many to list/edit sanely in that format. So the original reason I want to remove them is that they are very annoying, but the reasoning that then takes that annoyance and makes me think seriously about removing them despite the inevitable pain factor is that I really don't think we can even use the concept for any better model. Anything better would _have_ to be totally different. And no, I don't think your "diffs against a base" model work either, because while it would make them smaller, it would still make them basically unreadable and uneditable by any human, which means that it's not something we should check in - it's a generated file! And I do think our kernel configurator language already should basically have the expressive power to do it *sanely*. We already support including other files, which is a requirement for any hierarchical model. So I _think_ whatever "mach-xyz" file _should_ do something like # Kconfig file for OMAP4ABCXYZ chip .. set the particulars for this _particular_ chip, ie select the particular drivers on this chip .. include "chip-family-details" (ie maybe "base OMAP details") include "architecture-family-details" (ie ARM Kconfig) see? Not one flat file, and very much not something generated. And I actually suspect we could do it with our current Kconfig file model. IOW, in the arch/arm/Kconfig file, I think it should be doable to have basically a choice prompt "ARM platform" config ARM_PLATFORM_OMAP bool PLATFORM_OMAP config ARM_PLATFORM_MSM bool PLATFORM_MSM ... endchoice if ARK_PLATFORM_OMAP include "Kconfig.omap" # this will further have choices for OMAP versions elif ARM_PLATFORM_... and then the individual "Kconfig.platform" files could select certain options, and then do a "include Kconfig.cpu" which would actually be the _current_ top-level arch/arm/Kconfig. Or something. See? Making it hierarchical (so that each individual Kconfig.xyz file only handles a certain level of detail, and it doesn't grow unboundedly) and making it fundamentally human readable/writable would be a really good thing. NOTE NOTE NOTE! I'm not at all saying it has to be done like the above with the current Kconfig language. The above is more of a "this is how we _could_ do it, and it would be a big conceptual improvement". And I don't think we can get there from here unless I at some point say "I just removed the xyz_defconfig files", at which point people will curse me and stumble about until they actually come up with something better. Of course, if the ARM people do something proactive like the above _before_ I remove the defconfig files, I won't complain. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 14:48 ` ARM defconfig files Linus Torvalds @ 2010-06-03 16:46 ` Tony Lindgren 2010-06-03 18:13 ` Russell King 2010-06-03 16:53 ` Daniel Walker 2010-06-03 18:10 ` Russell King 2 siblings, 1 reply; 133+ messages in thread From: Tony Lindgren @ 2010-06-03 16:46 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm * Linus Torvalds <torvalds@linux-foundation.org> [100603 17:48]: > > So I _think_ whatever "mach-xyz" file _should_ do something like > > # Kconfig file for OMAP4ABCXYZ chip > > .. set the particulars for this _particular_ chip, > ie select the particular drivers on this chip .. > > include "chip-family-details" (ie maybe "base OMAP details") > > include "architecture-family-details" (ie ARM Kconfig) > > see? Not one flat file, and very much not something generated. > > And I actually suspect we could do it with our current Kconfig file model. > IOW, in the arch/arm/Kconfig file, I think it should be doable to have > basically a > > choice > prompt "ARM platform" > > config ARM_PLATFORM_OMAP > bool PLATFORM_OMAP > > config ARM_PLATFORM_MSM > bool PLATFORM_MSM > ... > endchoice > > if ARK_PLATFORM_OMAP > include "Kconfig.omap" # this will further have choices for OMAP versions > elif ARM_PLATFORM_... > > and then the individual "Kconfig.platform" files could select certain > options, and then do a "include Kconfig.cpu" which would actually be the > _current_ top-level arch/arm/Kconfig. Some of this work has been already done like I responded in the other thread. So we could use the current omap3_defconfig for omap2, 3 & 4 with some more work. Then do the same thing for omap1. That would cut it down by total of 38 defconfigs. Compiling in multiple ARM platforms is trickier, we would have to get rid of the duplicate defines like NR_IRQS, then have some common clock framework etc. Then figure out some way to get rid of Makefile.boot. Russell probably has some other things in mind that would have to be changed to make this happen. > And I don't think we can get there from here unless I at some point say "I > just removed the xyz_defconfig files", at which point people will curse me > and stumble about until they actually come up with something better. > > Of course, if the ARM people do something proactive like the above > _before_ I remove the defconfig files, I won't complain. Whenever you feel like it, please just go ahead and do: $ egrep "CONFIG_ARCH_OMAP[2|3|4]=y" arch/arm/configs/* | grep -v omap3_defconfig | cut -d: -f1 | xargs rm That way maybe you can wait a bit longer for the other defconfigs and as an extra bonus I won't get flamed for removing these omap defconfigs ;) Tony ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 16:46 ` Tony Lindgren @ 2010-06-03 18:13 ` Russell King 2010-06-03 21:33 ` Tony Lindgren ` (2 more replies) 0 siblings, 3 replies; 133+ messages in thread From: Russell King @ 2010-06-03 18:13 UTC (permalink / raw) To: Tony Lindgren Cc: Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: > Compiling in multiple ARM platforms is trickier, we would have to get > rid of the duplicate defines like NR_IRQS, then have some common clock > framework etc. Then figure out some way to get rid of Makefile.boot. > Russell probably has some other things in mind that would have to be > changed to make this happen. - Find someway to handle the wide variety of interrupt controllers. - Be able to handle any multitude of V:P translations, including non-linear alongside linear transations. - Different PAGE_OFFSETs - Different kernel VM layouts allowing for a variety of different ioremap region sizes and so the list goes on... > That way maybe you can wait a bit longer for the other defconfigs > and as an extra bonus I won't get flamed for removing these omap > defconfigs ;) Note that Linus is talking about removing all but one or two ARM defconfigs - which means your omap3_defconfig will probably be eventually culled. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:13 ` Russell King @ 2010-06-03 21:33 ` Tony Lindgren 2010-06-03 22:45 ` Nicolas Pitre 2010-06-04 0:23 ` Kevin Hilman 2010-06-04 1:02 ` Benjamin Herrenschmidt 2 siblings, 1 reply; 133+ messages in thread From: Tony Lindgren @ 2010-06-03 21:33 UTC (permalink / raw) To: Russell King Cc: Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm * Russell King <rmk@arm.linux.org.uk> [100603 21:07]: > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: > > Compiling in multiple ARM platforms is trickier, we would have to get > > rid of the duplicate defines like NR_IRQS, then have some common clock > > framework etc. Then figure out some way to get rid of Makefile.boot. > > Russell probably has some other things in mind that would have to be > > changed to make this happen. > > - Find someway to handle the wide variety of interrupt controllers. > - Be able to handle any multitude of V:P translations, including non-linear > alongside linear transations. > - Different PAGE_OFFSETs > - Different kernel VM layouts allowing for a variety of different ioremap > region sizes Some of these could be handled by allowing building a seprate instance for each platform compiled in. Maybe we could set them up with symlinks. How about a minimal generic relocatable ARM kernel and then we load the platform support as a module from ramdisk? :) > and so the list goes on... Yeah.. > > That way maybe you can wait a bit longer for the other defconfigs > > and as an extra bonus I won't get flamed for removing these omap > > defconfigs ;) > > Note that Linus is talking about removing all but one or two ARM > defconfigs - which means your omap3_defconfig will probably be > eventually culled. Yes but I also think we need to do something about this. Regards, Tony ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 21:33 ` Tony Lindgren @ 2010-06-03 22:45 ` Nicolas Pitre 2010-06-04 4:59 ` Tony Lindgren 0 siblings, 1 reply; 133+ messages in thread From: Nicolas Pitre @ 2010-06-03 22:45 UTC (permalink / raw) To: Tony Lindgren Cc: Russell King, Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Fri, 4 Jun 2010, Tony Lindgren wrote: > * Russell King <rmk@arm.linux.org.uk> [100603 21:07]: > > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: > > > Compiling in multiple ARM platforms is trickier, we would have to get > > > rid of the duplicate defines like NR_IRQS, then have some common clock > > > framework etc. Then figure out some way to get rid of Makefile.boot. > > > Russell probably has some other things in mind that would have to be > > > changed to make this happen. > > > > - Find someway to handle the wide variety of interrupt controllers. Eric Miao posted a patch series for that already. > > - Be able to handle any multitude of V:P translations, including non-linear > > alongside linear transations. Some effort is being deployed at my $job to do that. Initially only the linear translation will be supported, which should cover the vast majority of the cases already. The odd targets will simply require a build of their own like it is done today. > > - Different PAGE_OFFSETs Again, a majority of targets may simply share the default one. > > - Different kernel VM layouts allowing for a variety of different ioremap > > region sizes VMALLOC_END should only need to become a per machine class variable initialized at run time. > Some of these could be handled by allowing building a seprate instance > for each platform compiled in. Maybe we could set them up with symlinks. We already have runtime selectable machine instances. Building multiple machine class could extend on that. > How about a minimal generic relocatable ARM kernel and then we load the > platform support as a module from ramdisk? :) Pity... Nah. > > and so the list goes on... > > Yeah.. Like I said, there is an effort to gradually overcome those issues one by one. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 22:45 ` Nicolas Pitre @ 2010-06-04 4:59 ` Tony Lindgren 0 siblings, 0 replies; 133+ messages in thread From: Tony Lindgren @ 2010-06-04 4:59 UTC (permalink / raw) To: Nicolas Pitre Cc: Russell King, Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm * Nicolas Pitre <nico@fluxnic.net> [100604 01:40]: > > Like I said, there is an effort to gradually overcome those issues one > by one. Unfortunately the same time we are slowly adding more and more ifdef else code that adds new blockers to compile in multiple ARM platforms into the same kernel. Some of the ones I've ran into over past few months are CONFIG_HAS_TLS_REG, CONFIG_VFPv3 and CONFIG_SMP. The first two are fixable though. Anyways, once we get the TLS and VFPv3 issues sorted out, we can do ARMv6 and ARMv7 booting binaries so I'll be able to whine about any new blockers getting added :) Regards, Tony ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:13 ` Russell King 2010-06-03 21:33 ` Tony Lindgren @ 2010-06-04 0:23 ` Kevin Hilman 2010-06-04 4:53 ` Tony Lindgren 2010-06-04 1:02 ` Benjamin Herrenschmidt 2 siblings, 1 reply; 133+ messages in thread From: Kevin Hilman @ 2010-06-04 0:23 UTC (permalink / raw) To: Russell King Cc: Tony Lindgren, Linus Torvalds, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm Russell King <rmk@arm.linux.org.uk> writes: > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: >> Compiling in multiple ARM platforms is trickier, we would have to get >> rid of the duplicate defines like NR_IRQS, then have some common clock >> framework etc. Then figure out some way to get rid of Makefile.boot. >> Russell probably has some other things in mind that would have to be >> changed to make this happen. > > - Find someway to handle the wide variety of interrupt controllers. > - Be able to handle any multitude of V:P translations, including non-linear > alongside linear transations. > - Different PAGE_OFFSETs > - Different kernel VM layouts allowing for a variety of different ioremap > region sizes > > and so the list goes on... > - Support for ARMv5, v6 and v7 in the same kernel image. On davinci, we've recently run into the problem where a new SoC in the family is largely the same in terms of common HW blocks ands shared peripherals with other davincis, but they upgraded from ARMv5 to ARMv6. Attempting to build a single kernel that supports ARMv5 and ARMv6 uncovered a pile of assumptions that v5 and v6 would never be in the same kernel. Kevin ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-04 0:23 ` Kevin Hilman @ 2010-06-04 4:53 ` Tony Lindgren 0 siblings, 0 replies; 133+ messages in thread From: Tony Lindgren @ 2010-06-04 4:53 UTC (permalink / raw) To: Kevin Hilman Cc: Russell King, Linus Torvalds, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm * Kevin Hilman <khilman@deeprootsystems.com> [100604 03:17]: > Russell King <rmk@arm.linux.org.uk> writes: > > > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: > >> Compiling in multiple ARM platforms is trickier, we would have to get > >> rid of the duplicate defines like NR_IRQS, then have some common clock > >> framework etc. Then figure out some way to get rid of Makefile.boot. > >> Russell probably has some other things in mind that would have to be > >> changed to make this happen. > > > > - Find someway to handle the wide variety of interrupt controllers. > > - Be able to handle any multitude of V:P translations, including non-linear > > alongside linear transations. > > - Different PAGE_OFFSETs > > - Different kernel VM layouts allowing for a variety of different ioremap > > region sizes > > > > and so the list goes on... > > > > - Support for ARMv5, v6 and v7 in the same kernel image. > > On davinci, we've recently run into the problem where a new SoC in the > family is largely the same in terms of common HW blocks ands shared > peripherals with other davincis, but they upgraded from ARMv5 to > ARMv6. Attempting to build a single kernel that supports ARMv5 and > ARMv6 uncovered a pile of assumptions that v5 and v6 would never be in > the same kernel. Yeah we should sort that out, otherwise more things are slowly added that makes it harder to do. Regards, Tony ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:13 ` Russell King 2010-06-03 21:33 ` Tony Lindgren 2010-06-04 0:23 ` Kevin Hilman @ 2010-06-04 1:02 ` Benjamin Herrenschmidt 2010-06-04 5:29 ` Tony Lindgren 2010-06-04 6:30 ` Geert Uytterhoeven 2 siblings, 2 replies; 133+ messages in thread From: Benjamin Herrenschmidt @ 2010-06-04 1:02 UTC (permalink / raw) To: Russell King Cc: Tony Lindgren, Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote: > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: > > Compiling in multiple ARM platforms is trickier, we would have to get > > rid of the duplicate defines like NR_IRQS, then have some common clock > > framework etc. Then figure out some way to get rid of Makefile.boot. > > Russell probably has some other things in mind that would have to be > > changed to make this happen. Ok so multiple platforms in one kernel is a different subject and could warrant a different thread. However it's interesting because we do that quite well on powerpc :-) (Note also that while the device-tree helps make it even easier, it's not fundamentally necessary to achieve that goal). > - Find someway to handle the wide variety of interrupt controllers. We have a very nice and simple interrupt mapping scheme on powerpc that makes that quite trivial along with the generic irq changes that went in a couple of years ago (which we mostly based on ARM iirc). We have a structure that define an interrupt numbering domain (which can be associated 1:1 with a given controller but doesn't have to), and simple APIs to allocate "linux" interrupt numbers associated with a given domain/HW number pair. From there, we support multiple domains, arbitrary layout and cascades, etc... > - Be able to handle any multitude of V:P translations, including non-linear > alongside linear transations. For the kernel "linear" mapping you mean ? Yeah, that's a bit of a sore spot, though sparsemem + vmemmap helps a lot. Creative use of dynamic patching would do nicely here though it's problematic with XIP kernels (though my understanding is that those are getting less common). > - Different PAGE_OFFSETs Does this have to be a per SoC or mach family ? Users can change PAGE_OFFSET on powerpc to change the user/kernel split (for example in order to get more ioremap space or avoid turning on HIGHMEM) but it's in the domain of the config and a kernel with a lower PAGE_OFFSET can always boot all platforms even those that don't require it. Alternatively, you can always try to do like we do on ppc64 with fully runtime relocatable kernels :-) > - Different kernel VM layouts allowing for a variety of different ioremap > region sizes > > and so the list goes on... That's quite easily done at runtime. > > That way maybe you can wait a bit longer for the other defconfigs > > and as an extra bonus I won't get flamed for removing these omap > > defconfigs ;) > > Note that Linus is talking about removing all but one or two ARM > defconfigs - which means your omap3_defconfig will probably be > eventually culled. Cheers, Ben. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-04 1:02 ` Benjamin Herrenschmidt @ 2010-06-04 5:29 ` Tony Lindgren 2010-06-04 6:30 ` Geert Uytterhoeven 1 sibling, 0 replies; 133+ messages in thread From: Tony Lindgren @ 2010-06-04 5:29 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Russell King, Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm * Benjamin Herrenschmidt <benh@kernel.crashing.org> [100604 03:56]: > On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote: > > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: > > > Compiling in multiple ARM platforms is trickier, we would have to get > > > rid of the duplicate defines like NR_IRQS, then have some common clock > > > framework etc. Then figure out some way to get rid of Makefile.boot. > > > Russell probably has some other things in mind that would have to be > > > changed to make this happen. > > Ok so multiple platforms in one kernel is a different subject and could > warrant a different thread. However it's interesting because we do that > quite well on powerpc :-) > > (Note also that while the device-tree helps make it even easier, it's > not fundamentally necessary to achieve that goal). Yeah both platform data and device tree should work just fine. > > - Find someway to handle the wide variety of interrupt controllers. > > We have a very nice and simple interrupt mapping scheme on powerpc that > makes that quite trivial along with the generic irq changes that went in > a couple of years ago (which we mostly based on ARM iirc). > > We have a structure that define an interrupt numbering domain (which can > be associated 1:1 with a given controller but doesn't have to), and > simple APIs to allocate "linux" interrupt numbers associated with a > given domain/HW number pair. From there, we support multiple domains, > arbitrary layout and cascades, etc... > > > - Be able to handle any multitude of V:P translations, including non-linear > > alongside linear transations. > > For the kernel "linear" mapping you mean ? Yeah, that's a bit of a sore > spot, though sparsemem + vmemmap helps a lot. Creative use of dynamic > patching would do nicely here though it's problematic with XIP kernels > (though my understanding is that those are getting less common). > > > - Different PAGE_OFFSETs > > Does this have to be a per SoC or mach family ? Users can change > PAGE_OFFSET on powerpc to change the user/kernel split (for example in > order to get more ioremap space or avoid turning on HIGHMEM) but it's in > the domain of the config and a kernel with a lower PAGE_OFFSET can > always boot all platforms even those that don't require it. > > Alternatively, you can always try to do like we do on ppc64 with fully > runtime relocatable kernels :-) > > > - Different kernel VM layouts allowing for a variety of different ioremap > > region sizes > > > > and so the list goes on... > > That's quite easily done at runtime. Thanks for all the good info, that will be handy when trying to figure out how to change things to support multiple ARM platforms. Regards, Tony ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-04 1:02 ` Benjamin Herrenschmidt 2010-06-04 5:29 ` Tony Lindgren @ 2010-06-04 6:30 ` Geert Uytterhoeven 2010-06-04 6:53 ` Geert Uytterhoeven 2010-06-04 8:52 ` Benjamin Herrenschmidt 1 sibling, 2 replies; 133+ messages in thread From: Geert Uytterhoeven @ 2010-06-04 6:30 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Russell King, Tony Lindgren, Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Fri, Jun 4, 2010 at 03:02, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote: >> On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: >> > Compiling in multiple ARM platforms is trickier, we would have to get >> > rid of the duplicate defines like NR_IRQS, then have some common clock >> > framework etc. Then figure out some way to get rid of Makefile.boot. >> > Russell probably has some other things in mind that would have to be >> > changed to make this happen. > > Ok so multiple platforms in one kernel is a different subject and could Supporting multiple platforms matters a lot to keep everything (not just defconfigs) under control. Technically, on m68k we only need two defconfigs: sun3_defconfig (Sun 3 doesn't use a Motorola MMU) and multi_defconfig (which is the logical OR of all the other defconfigs, and which should work on all non-Sun 3). The reason we have the others is to ease building of platform-specific kernels that need less memory. I guess most of them can be (almost) regenerated from multi_defconfig just by disabling support for the other platforms. > warrant a different thread. However it's interesting because we do that > quite well on powerpc :-) So you could easily have one big common defconfig... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-04 6:30 ` Geert Uytterhoeven @ 2010-06-04 6:53 ` Geert Uytterhoeven 2010-06-04 8:52 ` Benjamin Herrenschmidt 1 sibling, 0 replies; 133+ messages in thread From: Geert Uytterhoeven @ 2010-06-04 6:53 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Russell King, Tony Lindgren, Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Fri, Jun 4, 2010 at 08:30, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Fri, Jun 4, 2010 at 03:02, Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: >> On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote: >>> On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: >>> > Compiling in multiple ARM platforms is trickier, we would have to get >>> > rid of the duplicate defines like NR_IRQS, then have some common clock >>> > framework etc. Then figure out some way to get rid of Makefile.boot. >>> > Russell probably has some other things in mind that would have to be >>> > changed to make this happen. >> >> Ok so multiple platforms in one kernel is a different subject and could > > Supporting multiple platforms matters a lot to keep everything (not just defconfigs) > under control. > > Technically, on m68k we only need two defconfigs: sun3_defconfig (Sun 3 doesn't > use a Motorola MMU) and multi_defconfig (which is the logical OR of all the other > defconfigs, and which should work on all non-Sun 3). Ah, I forgot... But indeed, most of the churn when updating the defconfigs (hmm, it's been a while I submitted an update) is in the non-arch part: disabling zillions of new options we don't want. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-04 6:30 ` Geert Uytterhoeven 2010-06-04 6:53 ` Geert Uytterhoeven @ 2010-06-04 8:52 ` Benjamin Herrenschmidt 1 sibling, 0 replies; 133+ messages in thread From: Benjamin Herrenschmidt @ 2010-06-04 8:52 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Russell King, Tony Lindgren, Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Fri, 2010-06-04 at 08:30 +0200, Geert Uytterhoeven wrote: > > > warrant a different thread. However it's interesting because we do > that > > quite well on powerpc :-) > > So you could easily have one big common defconfig... Well, there are things we still don't allow in one binary, and I suspect it would be nasty on ARM too, such as widely different core arch (which in ARM land would translate into widely different ARM architecture version). But yeah, we can pretty much make giant defconfigs. They are not very useful tho. In the embedded world, size constraints are quite strong and so you really need to be able to target only the subset of things you want for some types of devices. Of course, for things like ARM netbooks, it would be nice to have one giant defconfig that boots them all, and that's probably an achievable goal if the variants between bootloaders can be sorted out. Cheers, Ben. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 14:48 ` ARM defconfig files Linus Torvalds 2010-06-03 16:46 ` Tony Lindgren @ 2010-06-03 16:53 ` Daniel Walker 2010-06-08 15:30 ` Catalin Marinas 2010-06-03 18:10 ` Russell King 2 siblings, 1 reply; 133+ messages in thread From: Daniel Walker @ 2010-06-03 16:53 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, Vegard Nossum On Thu, 2010-06-03 at 07:48 -0700, Linus Torvalds wrote: > [ Continuation on the "ARM MSM updates" thread ] > > On Thu, 3 Jun 2010, Russell King wrote: > > > > It'd be nice if you'd copy me... > > Yeah, the thread started out as a "I got really bored with lots of msm > patches", and then just expanded into what I think is wrong with the > sub-architectures. > > > On the defconfig files, you may not like them - I don't like the > > proliferation of them either. What I've always wanted to see is > > one defconfig per class of machines - in other words, one mach-XXX. > > I can understand that, but at the same time, I do think that the > "defconfig" file concept as it is now is just broken. To the point of > being unfixable. It's obviously just a copy of the final .config, and it's > fundamentally not really readable (and especially not writable) by humans. > > And that all actually made some sense way-back-when, back when it was > originally done - back when our config files were tiny (compared to what > they are now), and when it ended up being the default input for the > config. It just doesn't make much sense any more. The Kconfig files > themselves end up having defaults for the core things, and the non-core > things are too many to list/edit sanely in that format. > > So the original reason I want to remove them is that they are very > annoying, but the reasoning that then takes that annoyance and makes me > think seriously about removing them despite the inevitable pain factor is > that I really don't think we can even use the concept for any better > model. > > Anything better would _have_ to be totally different. And no, I don't > think your "diffs against a base" model work either, because while it > would make them smaller, it would still make them basically unreadable and > uneditable by any human, which means that it's not something we should > check in - it's a generated file! Have you noticed this .. http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130 I'm not sure of the goals, but it sounds like it might be relevant. Daniel ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 16:53 ` Daniel Walker @ 2010-06-08 15:30 ` Catalin Marinas 2010-06-08 16:37 ` Daniel Walker 0 siblings, 1 reply; 133+ messages in thread From: Catalin Marinas @ 2010-06-08 15:30 UTC (permalink / raw) To: Daniel Walker Cc: Linus Torvalds, Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, Vegard Nossum Daniel Walker <dwalker@codeaurora.org> wrote: > Have you noticed this .. > > http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130 > > I'm not sure of the goals, but it sounds like it might be relevant. In some cases you don't want to automatically enable features but rather fix the Kconfig file. For example, with the select dependencies patch (http://lkml.org/lkml/2009/9/16/413) on ARMv7 RealView I get the following: warning: (CPU_V7 && !ARCH_OMAP2 || CPU_MMP2 && ARCH_MMP) selects CPU_32v6K which has unmet direct dependencies (CPU_V6) Unless I misunderstand this, a solver may try to select CPU_V6 which I don't want to. The solution is to fix Kconfig as below: Author: Catalin Marinas <catalin.marinas@arm.com> Date: Wed Aug 12 13:50:05 2009 +0100 Mark CPU_32v6K as depended on CPU_V7 Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 9f10a9b..a4909db 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -398,7 +398,7 @@ config CPU_V6 # ARMv6k config CPU_32v6K bool "Support ARM V6K processor extensions" if !SMP - depends on CPU_V6 + depends on CPU_V6 || CPU_V7 default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) help Say Y here if your ARMv6 processor supports the 'K' extension. -- Catalin ^ permalink raw reply related [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-08 15:30 ` Catalin Marinas @ 2010-06-08 16:37 ` Daniel Walker 0 siblings, 0 replies; 133+ messages in thread From: Daniel Walker @ 2010-06-08 16:37 UTC (permalink / raw) To: Catalin Marinas Cc: Linus Torvalds, Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, Vegard Nossum On Tue, 2010-06-08 at 16:30 +0100, Catalin Marinas wrote: > Daniel Walker <dwalker@codeaurora.org> wrote: > > Have you noticed this .. > > > > http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130 > > > > I'm not sure of the goals, but it sounds like it might be relevant. > > In some cases you don't want to automatically enable features but rather > fix the Kconfig file. For example, with the select dependencies patch > (http://lkml.org/lkml/2009/9/16/413) on ARMv7 RealView I get the > following: > > warning: (CPU_V7 && !ARCH_OMAP2 || CPU_MMP2 && ARCH_MMP) selects > CPU_32v6K which has unmet direct dependencies (CPU_V6) > > Unless I misunderstand this, a solver may try to select CPU_V6 which I > don't want to. The solution is to fix Kconfig as below: It seems like those are something the solver would likely find, or have problems with. Since we technically don't have a solver yet it's hard to say what the end result would be. None the less it's sucks we have things getting selected without their depends be met or correct.. Daniel ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 14:48 ` ARM defconfig files Linus Torvalds 2010-06-03 16:46 ` Tony Lindgren 2010-06-03 16:53 ` Daniel Walker @ 2010-06-03 18:10 ` Russell King 2010-06-03 18:18 ` Linus Torvalds 2010-06-03 18:20 ` Daniel Walker 2 siblings, 2 replies; 133+ messages in thread From: Russell King @ 2010-06-03 18:10 UTC (permalink / raw) To: Linus Torvalds Cc: Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 07:48:18AM -0700, Linus Torvalds wrote: > So I _think_ whatever "mach-xyz" file _should_ do something like > > # Kconfig file for OMAP4ABCXYZ chip > > .. set the particulars for this _particular_ chip, > ie select the particular drivers on this chip .. > > include "chip-family-details" (ie maybe "base OMAP details") > > include "architecture-family-details" (ie ARM Kconfig) > > see? Not one flat file, and very much not something generated. Umm... > And I actually suspect we could do it with our current Kconfig file model. > IOW, in the arch/arm/Kconfig file, I think it should be doable to have > basically a > > choice > prompt "ARM platform" > > config ARM_PLATFORM_OMAP > bool PLATFORM_OMAP > > config ARM_PLATFORM_MSM > bool PLATFORM_MSM > ... > endchoice Umm. I don't think you've actually looked at the Kconfig files if you're writing this, because that's precisely what we already do. arch/arm/Kconfig has a big choice statement in it to select the machine class, and then it sources the individual arch/arm/*/Kconfig files, which are themselves wrapped in a if FOO foo's options endif It's not one huge big "let's source everything and hope people ignore options which don't apply to their platform" that you seem to be implying we are doing. The big problem with doing away with the defconfig files is more to do with what happens _outside_ of arch/arm. At one time, I was phasing IDE out, and didn't want to see the "IDE" configuration options on platforms which either never had IDE support or had had IDE support removed - unfortunately I was overruled by the IDE/ATA developers and the conditionals we had went away. That's just one instance, but consider when you're presented with thousands of driver and filesystem configuration options as is the case with modern kernels. How do you find the few options you need to get to a point that the kernel you've built is actually useful? Anyway, I thought we were discussing _defconfig_ files, not Kconfig files... What we _could_ to is introduce a: config STD_CONFIG bool "Enable me to generate a standard configuration for your platform" and then have platforms conditionally select everything that's appropriate for their use. That provides a way to avoid the ages old issue of select forcing options on, but the user still being presented with the option and being told the only possible value for it is 'y'. And yes, it _is_ necessary - because if you want to turn off something on the platform - eg, you're not using MMC and MMC fails to build - you can still end up with a working configuration at the end of the day. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:10 ` Russell King @ 2010-06-03 18:18 ` Linus Torvalds 2010-06-03 18:53 ` Russell King 2010-06-03 18:20 ` Daniel Walker 1 sibling, 1 reply; 133+ messages in thread From: Linus Torvalds @ 2010-06-03 18:18 UTC (permalink / raw) To: Russell King Cc: Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Russell King wrote: > > Umm. I don't think you've actually looked at the Kconfig files if you're > writing this, because that's precisely what we already do. .. but if you do this _right_, then the defconfig files would be unnecessary. That's my point. If you are right, then I can remove the defconfig files entirely. Are you ready for that? And if you aren't ready for that, then what was the point of your email? Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:18 ` Linus Torvalds @ 2010-06-03 18:53 ` Russell King 2010-06-03 18:56 ` Linus Torvalds 2010-06-06 3:28 ` david 0 siblings, 2 replies; 133+ messages in thread From: Russell King @ 2010-06-03 18:53 UTC (permalink / raw) To: Linus Torvalds Cc: Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 11:18:05AM -0700, Linus Torvalds wrote: > > > On Thu, 3 Jun 2010, Russell King wrote: > > > > Umm. I don't think you've actually looked at the Kconfig files if you're > > writing this, because that's precisely what we already do. > > .. but if you do this _right_, then the defconfig files would be > unnecessary. > > That's my point. If you are right, then I can remove the defconfig files > entirely. Are you ready for that? Absolutely no way are we ready for that. > And if you aren't ready for that, then what was the point of your email? Linus, don't make this personal. The problem is NOT "what options which are found under the arch/arm tree do I need". The problem is "what options throughout the rest of the kernel do I need to result in a usable kernel". No amount of reorganising the Kconfig files into a heirarchial manner (which they already are) helps. Not one bit. Because they already are. That's not where the problem is. For instance, if I have platform A, I know it has an RTC. How do I know which of the 37 RTC drivers the kernel configuration presents me with to select? Am I really expected to open up the platform and read the device numbers off all the chips (some of which being surface mount are abbreviated) and work out that it's a TWL4030 RTC that I should be using? That's just one instance - and there's probably many more just like that. Just look at "multifunction drivers" for another case in point. How the hell do I know what multifunction driver is appropriate for a platform? Ditto "Power supply support". The list goes endlessly on. All those things I've mentioned are all _outside_ of arch/arm. That's where the _real_ problem is. Solve that problem so that it's easier for people to configure the kernel, and then we don't need the multitude defconfig files. That's the problem which the defconfigs are solving today. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:53 ` Russell King @ 2010-06-03 18:56 ` Linus Torvalds 2010-06-03 19:20 ` Russell King 2010-06-03 19:35 ` Daniel Walker 2010-06-06 3:28 ` david 1 sibling, 2 replies; 133+ messages in thread From: Linus Torvalds @ 2010-06-03 18:56 UTC (permalink / raw) To: Russell King Cc: Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Russell King wrote: > > No amount of reorganising the Kconfig files into a heirarchial manner > (which they already are) helps. Not one bit. Because they already are. > That's not where the problem is. I don't think you read the whole thread. Earlier on, I explained exactly what I wanted: just add some "select" statements to pickt he things you need per the particular target configuration. You seem to have missed that part. In other words, you _can_ encode the information that is in the xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do it in a human-readable manner. And the hierarchical thing is absolutely required for that - otherwise you'd end up with just another form of the current xyz_defconfig. See? In other words, you should be able to basically use "make allnoconfig" together with a Kconfig.xyz file input to select _exactly_ the pieces you need, and nothing else. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:56 ` Linus Torvalds @ 2010-06-03 19:20 ` Russell King 2010-06-03 19:35 ` Daniel Walker 1 sibling, 0 replies; 133+ messages in thread From: Russell King @ 2010-06-03 19:20 UTC (permalink / raw) To: Linus Torvalds Cc: Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 11:56:53AM -0700, Linus Torvalds wrote: > > > On Thu, 3 Jun 2010, Russell King wrote: > > > > No amount of reorganising the Kconfig files into a heirarchial manner > > (which they already are) helps. Not one bit. Because they already are. > > That's not where the problem is. > > I don't think you read the whole thread. > > Earlier on, I explained exactly what I wanted: just add some "select" > statements to pickt he things you need per the particular target > configuration. You seem to have missed that part. Isn't that _also_ what I suggested with one modification - which was based on your suggestion with a _bit_ _more_ _thought_? Oddly that suggestion which you appear to have completely ignored - but clearly you did get the mail because you quoted a few lines from it in one of your subsequent replies - was based on your very idea. The one which you said "what was the point of your mail". Maybe the point is to discuss issues. You know, it's exceedingly difficult to discuss things if the other side doesn't read messages they're sent. Ergo, I don't think there's any point discussing this any further; you've crystal clearly already stopped listening. Maybe you should go back to that one which you gave such a flippant reply to and re-read it, and actually productively comment on my additional suggestion to yours? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:56 ` Linus Torvalds 2010-06-03 19:20 ` Russell King @ 2010-06-03 19:35 ` Daniel Walker 2010-06-03 19:45 ` Russell King 2010-06-03 20:05 ` Linus Torvalds 1 sibling, 2 replies; 133+ messages in thread From: Daniel Walker @ 2010-06-03 19:35 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote: > > On Thu, 3 Jun 2010, Russell King wrote: > > > > No amount of reorganising the Kconfig files into a heirarchial manner > > (which they already are) helps. Not one bit. Because they already are. > > That's not where the problem is. > > I don't think you read the whole thread. > > Earlier on, I explained exactly what I wanted: just add some "select" > statements to pickt he things you need per the particular target > configuration. You seem to have missed that part. > > In other words, you _can_ encode the information that is in the > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do > it in a human-readable manner. And the hierarchical thing is absolutely > required for that - otherwise you'd end up with just another form of the > current xyz_defconfig. > > See? > > In other words, you should be able to basically use "make allnoconfig" > together with a Kconfig.xyz file input to select _exactly_ the pieces you > need, and nothing else. If you did this for drivers, what about disabling a driver? If we used "select" wouldn't that force all the drivers on without allowing it to be unselected? Daniel ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 19:35 ` Daniel Walker @ 2010-06-03 19:45 ` Russell King 2010-06-03 19:49 ` Daniel Walker 2010-06-03 20:09 ` Linus Torvalds 2010-06-03 20:05 ` Linus Torvalds 1 sibling, 2 replies; 133+ messages in thread From: Russell King @ 2010-06-03 19:45 UTC (permalink / raw) To: Daniel Walker Cc: Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 12:35:42PM -0700, Daniel Walker wrote: > On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote: > > > > On Thu, 3 Jun 2010, Russell King wrote: > > > > > > No amount of reorganising the Kconfig files into a heirarchial manner > > > (which they already are) helps. Not one bit. Because they already are. > > > That's not where the problem is. > > > > I don't think you read the whole thread. > > > > Earlier on, I explained exactly what I wanted: just add some "select" > > statements to pickt he things you need per the particular target > > configuration. You seem to have missed that part. > > > > In other words, you _can_ encode the information that is in the > > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do > > it in a human-readable manner. And the hierarchical thing is absolutely > > required for that - otherwise you'd end up with just another form of the > > current xyz_defconfig. > > > > See? > > > > In other words, you should be able to basically use "make allnoconfig" > > together with a Kconfig.xyz file input to select _exactly_ the pieces you > > need, and nothing else. > > If you did this for drivers, what about disabling a driver? If we used > "select" wouldn't that force all the drivers on without allowing it to > be unselected? I already covered that in my (ignored) email where I brought up a "STD_CONFIG" config symbol, which could be disabled to turn off all these additional "select"s. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 19:45 ` Russell King @ 2010-06-03 19:49 ` Daniel Walker 2010-06-03 19:57 ` Russell King 2010-06-03 20:09 ` Linus Torvalds 1 sibling, 1 reply; 133+ messages in thread From: Daniel Walker @ 2010-06-03 19:49 UTC (permalink / raw) To: Russell King Cc: Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 2010-06-03 at 20:45 +0100, Russell King wrote: > On Thu, Jun 03, 2010 at 12:35:42PM -0700, Daniel Walker wrote: > > On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote: > > > > > > On Thu, 3 Jun 2010, Russell King wrote: > > > > > > > > No amount of reorganising the Kconfig files into a heirarchial manner > > > > (which they already are) helps. Not one bit. Because they already are. > > > > That's not where the problem is. > > > > > > I don't think you read the whole thread. > > > > > > Earlier on, I explained exactly what I wanted: just add some "select" > > > statements to pickt he things you need per the particular target > > > configuration. You seem to have missed that part. > > > > > > In other words, you _can_ encode the information that is in the > > > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do > > > it in a human-readable manner. And the hierarchical thing is absolutely > > > required for that - otherwise you'd end up with just another form of the > > > current xyz_defconfig. > > > > > > See? > > > > > > In other words, you should be able to basically use "make allnoconfig" > > > together with a Kconfig.xyz file input to select _exactly_ the pieces you > > > need, and nothing else. > > > > If you did this for drivers, what about disabling a driver? If we used > > "select" wouldn't that force all the drivers on without allowing it to > > be unselected? > > I already covered that in my (ignored) email where I brought up a > "STD_CONFIG" config symbol, which could be disabled to turn off all > these additional "select"s. I didn't ignore it, I guess I just didn't fully understand it .. So your saying it would drop all the selects, but keep the selected options in tact? Or it would just turn off all the selected options? Daniel ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 19:49 ` Daniel Walker @ 2010-06-03 19:57 ` Russell King 2010-06-03 20:06 ` Daniel Walker ` (2 more replies) 0 siblings, 3 replies; 133+ messages in thread From: Russell King @ 2010-06-03 19:57 UTC (permalink / raw) To: Daniel Walker Cc: Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote: > On Thu, 2010-06-03 at 20:45 +0100, Russell King wrote: > > On Thu, Jun 03, 2010 at 12:35:42PM -0700, Daniel Walker wrote: > > > On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote: > > > > > > > > On Thu, 3 Jun 2010, Russell King wrote: > > > > > > > > > > No amount of reorganising the Kconfig files into a heirarchial manner > > > > > (which they already are) helps. Not one bit. Because they already are. > > > > > That's not where the problem is. > > > > > > > > I don't think you read the whole thread. > > > > > > > > Earlier on, I explained exactly what I wanted: just add some "select" > > > > statements to pickt he things you need per the particular target > > > > configuration. You seem to have missed that part. > > > > > > > > In other words, you _can_ encode the information that is in the > > > > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do > > > > it in a human-readable manner. And the hierarchical thing is absolutely > > > > required for that - otherwise you'd end up with just another form of the > > > > current xyz_defconfig. > > > > > > > > See? > > > > > > > > In other words, you should be able to basically use "make allnoconfig" > > > > together with a Kconfig.xyz file input to select _exactly_ the pieces you > > > > need, and nothing else. > > > > > > If you did this for drivers, what about disabling a driver? If we used > > > "select" wouldn't that force all the drivers on without allowing it to > > > be unselected? > > > > I already covered that in my (ignored) email where I brought up a > > "STD_CONFIG" config symbol, which could be disabled to turn off all > > these additional "select"s. > > I didn't ignore it, I guess I just didn't fully understand it .. > > So your saying it would drop all the selects, but keep the selected > options in tact? Or it would just turn off all the selected options? config MACH_HALIBUT bool "Halibut Board (QCT SURF7201A)" select I2C if STD_CONFIG select I2C_WHATEVER if STD_CONFIG ... That means if you enable STD_CONFIG, you'll get everything that's required selected. If you then disable STD_CONFIG, I believe Kconfig leaves everything that was selected as still being selected. So, what you _could_ do is start off with a blank configuration, then configure a kernel with STD_CONFIG enabled and you end up with everything that's required. If you then want to disable something that's selected, turn off STD_CONFIG first, and you'll be able to turn off individual options. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 19:57 ` Russell King @ 2010-06-03 20:06 ` Daniel Walker 2010-06-03 20:18 ` Russell King 2010-06-03 20:20 ` Nicolas Pitre 2010-06-04 1:06 ` Benjamin Herrenschmidt 2 siblings, 1 reply; 133+ messages in thread From: Daniel Walker @ 2010-06-03 20:06 UTC (permalink / raw) To: Russell King Cc: Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 2010-06-03 at 20:57 +0100, Russell King wrote: > On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote: > > On Thu, 2010-06-03 at 20:45 +0100, Russell King wrote: > > > On Thu, Jun 03, 2010 at 12:35:42PM -0700, Daniel Walker wrote: > > > > On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote: > > > > > > > > > > On Thu, 3 Jun 2010, Russell King wrote: > > > > > > > > > > > > No amount of reorganising the Kconfig files into a heirarchial manner > > > > > > (which they already are) helps. Not one bit. Because they already are. > > > > > > That's not where the problem is. > > > > > > > > > > I don't think you read the whole thread. > > > > > > > > > > Earlier on, I explained exactly what I wanted: just add some "select" > > > > > statements to pickt he things you need per the particular target > > > > > configuration. You seem to have missed that part. > > > > > > > > > > In other words, you _can_ encode the information that is in the > > > > > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do > > > > > it in a human-readable manner. And the hierarchical thing is absolutely > > > > > required for that - otherwise you'd end up with just another form of the > > > > > current xyz_defconfig. > > > > > > > > > > See? > > > > > > > > > > In other words, you should be able to basically use "make allnoconfig" > > > > > together with a Kconfig.xyz file input to select _exactly_ the pieces you > > > > > need, and nothing else. > > > > > > > > If you did this for drivers, what about disabling a driver? If we used > > > > "select" wouldn't that force all the drivers on without allowing it to > > > > be unselected? > > > > > > I already covered that in my (ignored) email where I brought up a > > > "STD_CONFIG" config symbol, which could be disabled to turn off all > > > these additional "select"s. > > > > I didn't ignore it, I guess I just didn't fully understand it .. > > > > So your saying it would drop all the selects, but keep the selected > > options in tact? Or it would just turn off all the selected options? > > config MACH_HALIBUT > bool "Halibut Board (QCT SURF7201A)" > select I2C if STD_CONFIG > select I2C_WHATEVER if STD_CONFIG > ... > > That means if you enable STD_CONFIG, you'll get everything that's required > selected. If you then disable STD_CONFIG, I believe Kconfig leaves > everything that was selected as still being selected. I just did a little test, and it doesn't. Kconfig would un-select all the drivers, at least from my test. > So, what you _could_ do is start off with a blank configuration, then > configure a kernel with STD_CONFIG enabled and you end up with everything > that's required. If you then want to disable something that's selected, > turn off STD_CONFIG first, and you'll be able to turn off individual > options. If my test was correct we would need a new "select" variant that would leave the options turned on in order to get something equal to the current defconfigs. Daniel ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 20:06 ` Daniel Walker @ 2010-06-03 20:18 ` Russell King 0 siblings, 0 replies; 133+ messages in thread From: Russell King @ 2010-06-03 20:18 UTC (permalink / raw) To: Daniel Walker Cc: Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 01:06:48PM -0700, Daniel Walker wrote: > On Thu, 2010-06-03 at 20:57 +0100, Russell King wrote: > > config MACH_HALIBUT > > bool "Halibut Board (QCT SURF7201A)" > > select I2C if STD_CONFIG > > select I2C_WHATEVER if STD_CONFIG > > ... > > > > That means if you enable STD_CONFIG, you'll get everything that's required > > selected. If you then disable STD_CONFIG, I believe Kconfig leaves > > everything that was selected as still being selected. > > I just did a little test, and it doesn't. Kconfig would un-select all > the drivers, at least from my test. That's because it knows what the original state of the symbol is. Yes, that's a little undesirable for our behaviour - but it can be worked around - by saving and restarting Kconfig. Try this: config STD_CONFIG bool "Standard config" default y config DRIVER_A tristate "Driver A" config ARM def_bool y select DRIVER_A if STD_CONFIG and in a new directory /path/to/kernel/scripts/kconfig/mconf test.conf If you turn off STD_CONFIG immediately, it'll turn off DRIVER_A. However, save out the config, and re-run mconf test.conf. You'll then find that DRIVER_A remains set even when STD_CONFIG is turned off. So, Kconfig does have the behaviour we desire but it's not directly accessible. Is it worth persuing? Will Linus accept this STD_CONFIG idea or did his lack of reply to it indicate that he's not something he's willing to entertain? In any case, this is my last mail on the subject. I won't be replying to mail for at least the next four days. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 19:57 ` Russell King 2010-06-03 20:06 ` Daniel Walker @ 2010-06-03 20:20 ` Nicolas Pitre 2010-06-04 1:06 ` Benjamin Herrenschmidt 2 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-06-03 20:20 UTC (permalink / raw) To: Russell King Cc: Daniel Walker, Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Russell King wrote: > On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote: > > So your saying it would drop all the selects, but keep the selected > > options in tact? Or it would just turn off all the selected options? > > config MACH_HALIBUT > bool "Halibut Board (QCT SURF7201A)" > select I2C if STD_CONFIG > select I2C_WHATEVER if STD_CONFIG > ... > > That means if you enable STD_CONFIG, you'll get everything that's required > selected. If you then disable STD_CONFIG, I believe Kconfig leaves > everything that was selected as still being selected. > > So, what you _could_ do is start off with a blank configuration, then > configure a kernel with STD_CONFIG enabled and you end up with everything > that's required. If you then want to disable something that's selected, > turn off STD_CONFIG first, and you'll be able to turn off individual > options. I think this certainly makes sense, at least as a proof of concept. If we end up with lots of select XYZ if STD_CONFIG then at that point it might be a good idea to introduce some variations in the Kconfig language directly. Something like a multi-priority select statement that would either: - provide the minimum amount of choice to the user and forcefully "select" a default set of options expected to enable all features of the target hardware, or - let the user see the "preselected" options with a chance to turn it off, but provide a y by default right away, or - ignore those "preselect" statement entirely, as some expert mode. Of course the 2nd and 3rd options wouldn't necessarily mean an optimal or even working kernel configuration would be produced. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 19:57 ` Russell King 2010-06-03 20:06 ` Daniel Walker 2010-06-03 20:20 ` Nicolas Pitre @ 2010-06-04 1:06 ` Benjamin Herrenschmidt 2 siblings, 0 replies; 133+ messages in thread From: Benjamin Herrenschmidt @ 2010-06-04 1:06 UTC (permalink / raw) To: Russell King Cc: Daniel Walker, Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 2010-06-03 at 20:57 +0100, Russell King wrote: > config MACH_HALIBUT > bool "Halibut Board (QCT SURF7201A)" > select I2C if STD_CONFIG > select I2C_WHATEVER if STD_CONFIG > ... > > That means if you enable STD_CONFIG, you'll get everything that's required > selected. If you then disable STD_CONFIG, I believe Kconfig leaves > everything that was selected as still being selected. > > So, what you _could_ do is start off with a blank configuration, then > configure a kernel with STD_CONFIG enabled and you end up with everything > that's required. If you then want to disable something that's selected, > turn off STD_CONFIG first, and you'll be able to turn off individual > options. The main problem with that approach is that you can't choose what is to be modules and what is to be built-in. Yes, I do -hate- modules as much as you do. However, I have for example that little ARM based NAS box (DNS-323 from Belkin) and the firmware on that thing won't let me boot a kernel that is more than about 1.5M, tho I have about 6M of flash to put an initramfs with modules in it. Maybe we could extend select that way. IE. A way to say that a given option should be y or m by default, for example, while the user can still change it to be the other way around ? Cheers, Ben. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 19:45 ` Russell King 2010-06-03 19:49 ` Daniel Walker @ 2010-06-03 20:09 ` Linus Torvalds 2010-06-03 20:31 ` Linus Torvalds 2010-06-03 20:34 ` Nicolas Pitre 1 sibling, 2 replies; 133+ messages in thread From: Linus Torvalds @ 2010-06-03 20:09 UTC (permalink / raw) To: Russell King Cc: Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Russell King wrote: > > I already covered that in my (ignored) email where I brought up a > "STD_CONFIG" config symbol, which could be disabled to turn off all > these additional "select"s. I apparently haven't explained myself enough, because what you keep on harping on is not something I consider acceptable. STD_CONFIG is pointless. It's pointless because the solution to what you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz file at all. So when I suggest special Kconfig files, they are meant to just generate the templates - ie they'd _generate_ what is currently the defconfig files. You wouldn't _have_ to use them at all. If you _had_ to use them, you'd lose the flexibility of Kconfig and asking questions. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 20:09 ` Linus Torvalds @ 2010-06-03 20:31 ` Linus Torvalds 2010-06-03 21:17 ` Tony Lindgren ` (3 more replies) 2010-06-03 20:34 ` Nicolas Pitre 1 sibling, 4 replies; 133+ messages in thread From: Linus Torvalds @ 2010-06-03 20:31 UTC (permalink / raw) To: Russell King Cc: Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Linus Torvalds wrote: > > I apparently haven't explained myself enough, because what you keep on > harping on is not something I consider acceptable. > > STD_CONFIG is pointless. It's pointless because the solution to what > you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz > file at all. To make this _really_ concrete, let me actually give you an example (but broken and pointless) example Kconfig file, in order to _avoid_ having a def_config file. I do it by generating it. Let's say that I want a x86 configuration that has USB enabled. I can basically _ask_ the Kconfig machinery to generate that with something like this: - create a "Mykconfig" file: config MYCONFIG bool default y select USB source arch/x86/Kconfig and then I just do KBUILD_KCONFIG=Mykconfig make allnoconfig and look what appears in the .config file. In fact, do this: make allnoconfig cp .config no-config KBUILD_KCONFIG=Mykconfig make allnoconfig cp .config my-config diff -u no-config my-config to see the point of it all. Now, the above is a _trivial_ one. And it's actually broken, because I should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT). But with this approach you could basically generate the defconfig files. And exactly because Kconfig files are already hierarchical, you can do things like - Kconfig.omap3_evm: # Set the OMAP3 EVM-specific parts config OMAP3EVM bool default y select OMAP3_EVM_TIMERS # whatever ... # this sets the thngs all OMAP3 cases want source Kconfig.omap3 - Kconfig.omap3 # Set the OMAP3 specific parts config OMAP3 bool default y select USB_SUPPORT select USB ... source Kconfig.arm and now you'd be able to basically generate a OMAP3EVM .config file by just running "allnoconfig" on that Kconfig.omap3_evm file. But it would only have to select the parts that are specific for the EVM platform, because the generic OMAP3 support would be picked by the Kconfig.omap3 file, which in turn would not have to worry about the generic ARM parts etc. See? Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 20:31 ` Linus Torvalds @ 2010-06-03 21:17 ` Tony Lindgren 2010-06-03 22:15 ` Grant Likely ` (2 more replies) 2010-06-03 21:48 ` Daniel Walker ` (2 subsequent siblings) 3 siblings, 3 replies; 133+ messages in thread From: Tony Lindgren @ 2010-06-03 21:17 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm * Linus Torvalds <torvalds@linux-foundation.org> [100603 23:30]: > > and now you'd be able to basically generate a OMAP3EVM .config file by > just running "allnoconfig" on that Kconfig.omap3_evm file. But it would > only have to select the parts that are specific for the EVM platform, > because the generic OMAP3 support would be picked by the Kconfig.omap3 > file, which in turn would not have to worry about the generic ARM parts > etc. > > See? Sounds like a good improvment to me. Tony ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 21:17 ` Tony Lindgren @ 2010-06-03 22:15 ` Grant Likely 2010-06-04 5:18 ` Felipe Balbi 2010-06-04 11:31 ` Catalin Marinas 2010-06-03 22:24 ` Daniel Walker 2010-06-05 14:12 ` Felipe Contreras 2 siblings, 2 replies; 133+ messages in thread From: Grant Likely @ 2010-06-03 22:15 UTC (permalink / raw) To: Tony Lindgren, Linus Torvalds Cc: Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 3, 2010 at 3:17 PM, Tony Lindgren <tony@atomide.com> wrote: > * Linus Torvalds <torvalds@linux-foundation.org> [100603 23:30]: >> >> and now you'd be able to basically generate a OMAP3EVM .config file by >> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would >> only have to select the parts that are specific for the EVM platform, >> because the generic OMAP3 support would be picked by the Kconfig.omap3 >> file, which in turn would not have to worry about the generic ARM parts >> etc. >> >> See? > > Sounds like a good improvment to me. (as one who just finishing updating powerpc defconfigs...) ditto here. I'd be happy to be rid of all the existing ppc defconfigs. I like the Kconfig approach, but to be useful (at least for me) there would need to be a way to get Kconfig to complain about things like broken selects as in your example. g. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 22:15 ` Grant Likely @ 2010-06-04 5:18 ` Felipe Balbi 2010-06-04 11:31 ` Catalin Marinas 1 sibling, 0 replies; 133+ messages in thread From: Felipe Balbi @ 2010-06-04 5:18 UTC (permalink / raw) To: ext Grant Likely Cc: Tony Lindgren, Linus Torvalds, Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Fri, Jun 04, 2010 at 12:15:45AM +0200, ext Grant Likely wrote: >On Thu, Jun 3, 2010 at 3:17 PM, Tony Lindgren <tony@atomide.com> wrote: >> * Linus Torvalds <torvalds@linux-foundation.org> [100603 23:30]: >>> >>> and now you'd be able to basically generate a OMAP3EVM .config file by >>> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would >>> only have to select the parts that are specific for the EVM platform, >>> because the generic OMAP3 support would be picked by the Kconfig.omap3 >>> file, which in turn would not have to worry about the generic ARM parts >>> etc. >>> >>> See? >> >> Sounds like a good improvment to me. > >(as one who just finishing updating powerpc defconfigs...) ditto here. > I'd be happy to be rid of all the existing ppc defconfigs. > >I like the Kconfig approach, but to be useful (at least for me) there >would need to be a way to get Kconfig to complain about things like >broken selects as in your example. Still selects needs to be improved so we have a 'select_module' option that would make that driver a module instead of built-in. -- balbi DefectiveByDesign.org ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 22:15 ` Grant Likely 2010-06-04 5:18 ` Felipe Balbi @ 2010-06-04 11:31 ` Catalin Marinas 1 sibling, 0 replies; 133+ messages in thread From: Catalin Marinas @ 2010-06-04 11:31 UTC (permalink / raw) To: Grant Likely Cc: Tony Lindgren, Linus Torvalds, Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm Grant Likely <grant.likely@secretlab.ca> wrote: > On Thu, Jun 3, 2010 at 3:17 PM, Tony Lindgren <tony@atomide.com> wrote: >> * Linus Torvalds <torvalds@linux-foundation.org> [100603 23:30]: >>> >>> and now you'd be able to basically generate a OMAP3EVM .config file by >>> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would >>> only have to select the parts that are specific for the EVM platform, >>> because the generic OMAP3 support would be picked by the Kconfig.omap3 >>> file, which in turn would not have to worry about the generic ARM parts >>> etc. >>> >>> See? >> >> Sounds like a good improvment to me. > > (as one who just finishing updating powerpc defconfigs...) ditto here. > I'd be happy to be rid of all the existing ppc defconfigs. > > I like the Kconfig approach, but to be useful (at least for me) there > would need to be a way to get Kconfig to complain about things like > broken selects as in your example. There was an attempt to fix this (I can re-post if people are interested): http://lkml.org/lkml/2009/9/16/413 -- Catalin ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 21:17 ` Tony Lindgren 2010-06-03 22:15 ` Grant Likely @ 2010-06-03 22:24 ` Daniel Walker 2010-06-05 14:12 ` Felipe Contreras 2 siblings, 0 replies; 133+ messages in thread From: Daniel Walker @ 2010-06-03 22:24 UTC (permalink / raw) To: Tony Lindgren Cc: Linus Torvalds, Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Fri, 2010-06-04 at 00:17 +0300, Tony Lindgren wrote: > * Linus Torvalds <torvalds@linux-foundation.org> [100603 23:30]: > > > > and now you'd be able to basically generate a OMAP3EVM .config file by > > just running "allnoconfig" on that Kconfig.omap3_evm file. But it would > > only have to select the parts that are specific for the EVM platform, > > because the generic OMAP3 support would be picked by the Kconfig.omap3 > > file, which in turn would not have to worry about the generic ARM parts > > etc. > > > > See? > > Sounds like a good improvment to me. I was looking at this new defconfig added this merge window, omap3_stalker_lks_defconig .. diff -u arch/arm/configs/omap3_defconfig arch/arm/configs/omap3_stalker_lks_defconfig | diffstat omap3_stalker_lks_defconfig | 850 +++++++------------------------------------- 1 file changed, 140 insertions(+), 710 deletions(-) There's a lot of stuff that's different in there .. If I look through it, there's stuff that's not related to OMAP , or even drivers. Like Kprobes gets disabled over omap3_defconfig . To me that's kind of messy .. It should really be just what the user absolutely needs. I think we're able to get away with that now cause no one cares enough to really read the defconfig and see what's going on. Having stuff like that adds more flux. Whatever scheme we go to would likely change that and people would actually read what's going on. So we wouldn't be able to randomly have Kprobes enabled in one config, and not enabled in another one. Or having a debug config as one, then having a performance config for another. Daniel ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 21:17 ` Tony Lindgren 2010-06-03 22:15 ` Grant Likely 2010-06-03 22:24 ` Daniel Walker @ 2010-06-05 14:12 ` Felipe Contreras 2010-06-05 14:39 ` Linus Torvalds 2 siblings, 1 reply; 133+ messages in thread From: Felipe Contreras @ 2010-06-05 14:12 UTC (permalink / raw) To: Tony Lindgren Cc: Linus Torvalds, Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, Vegard Nossum [-- Attachment #1: Type: text/plain, Size: 1403 bytes --] On Fri, Jun 4, 2010 at 12:17 AM, Tony Lindgren <tony@atomide.com> wrote: > * Linus Torvalds <torvalds@linux-foundation.org> [100603 23:30]: >> >> and now you'd be able to basically generate a OMAP3EVM .config file by >> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would >> only have to select the parts that are specific for the EVM platform, >> because the generic OMAP3 support would be picked by the Kconfig.omap3 >> file, which in turn would not have to worry about the generic ARM parts >> etc. >> >> See? > > Sounds like a good improvment to me. How about instead of using full defconfigs, we use minimal ones and let the rest be determined with defaults. For example, omap3_beagle.baseconfig would have something like: CONFIG_MACH_OMAP3_BEAGLE=y CONFIG_ARCH_OMAP=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP3430=y CONFIG_AEABI=y CONFIG_EMBEDDED=y CONFIG_ARCH_OMAP_OTG=y CONFIG_OMAP_MUX=n CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_DM_TIMER=y CONFIG_INPUT_MOUSE=n You copy that to the .config, and then do: echo "" | make ARCH=arm oldconfig The result would be exactly the same as we have now. With the SAT resolver I think it should be possible to automatically simply the current defconfigs. (CC'ing Vegard for comments) I'm attaching a simplified base config, that I used to test this, and the result is an exact match of the current omap3_beagle_defconfig. -- Felipe Contreras [-- Attachment #2: omap3_beagle.config --] [-- Type: application/octet-stream, Size: 3546 bytes --] CONFIG_MACH_OMAP3_BEAGLE=y # these should be automatic CONFIG_ARCH_OMAP=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP3430=y # probably this too CONFIG_AEABI=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_FREEZER=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_BLK_DEV_INITRD=y CONFIG_EMBEDDED=y CONFIG_SLAB=y CONFIG_ARCH_VERSATILE=n CONFIG_BLK_DEV_BSG=n CONFIG_SYSCTL_SYSCALL=n CONFIG_NAMESPACES=n CONFIG_RD_BZIP2=n CONFIG_RD_LZMA=n CONFIG_RD_LZO=n CONFIG_ARCH_OMAP_OTG=y CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_MUX=n CONFIG_OMAP_MCBSP=n CONFIG_OMAP_DM_TIMER=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_FPE_NWFPE=y CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_BINFMT_MISC=y CONFIG_PM=y CONFIG_PM_RUNTIME=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y CONFIG_INET_TUNNEL=n CONFIG_INET_LRO=n CONFIG_IPV6=n CONFIG_FW_LOADER=n CONFIG_MTD=y CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y CONFIG_MTD_NAND=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y # not needed, right? CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_MISC_DEVICES=n # cdrom? seriously? CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_NETDEVICES=y # these should be off by default CONFIG_NETDEV_1000=n CONFIG_NETDEV_10000=n CONFIG_INPUT_MOUSEDEV=n CONFIG_INPUT_KEYBOARD=n CONFIG_INPUT_MOUSE=n CONFIG_LEGACY_PTYS=n CONFIG_SERIO=n CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y # could this be automatic? CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_HW_RANDOM=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y # this should be automatic, right? CONFIG_I2C_OMAP=y CONFIG_REGULATOR=y # should be on by default of omap3, no? CONFIG_GPIO_TWL4030=y CONFIG_TWL4030_CORE=y CONFIG_REGULATOR_TWL4030=y CONFIG_HWMON=n CONFIG_FB=y CONFIG_FB_OMAP=y # should depend on FB CONFIG_VGA_CONSOLE=n # should be auto CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y # are these needed? CONFIG_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_HID_SUPPORT=n CONFIG_USB=y CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_OTG=y CONFIG_USB_MON=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_MUSB_HDRC=y CONFIG_USB_MUSB_OTG=y CONFIG_USB_MUSB_HOST=n CONFIG_USB_GADGET_MUSB_HDRC=y CONFIG_USB_GADGET=y CONFIG_USB_OTG_WHITELIST=n # useful on beagleboard CONFIG_USB_ETH=m CONFIG_TWL4030_USB=y CONFIG_MMC=y CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=n CONFIG_INOTIFY=y CONFIG_QUOTA=y CONFIG_QUOTA_TREE=y CONFIG_QFMT_V2=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_JFFS2_FS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y CONFIG_PARTITION_ADVANCED=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_BUGVERBOSE=n CONFIG_DEBUG_INFO=y CONFIG_FTRACE=n CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_CRC32C=y CONFIG_CRC_CCITT=y CONFIG_LIBCRC32C=y # system-specific CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0:off rw console=ttyS2,115200n8" ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-05 14:12 ` Felipe Contreras @ 2010-06-05 14:39 ` Linus Torvalds 2010-06-05 16:39 ` Felipe Contreras 0 siblings, 1 reply; 133+ messages in thread From: Linus Torvalds @ 2010-06-05 14:39 UTC (permalink / raw) To: Felipe Contreras Cc: Tony Lindgren, Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, Vegard Nossum On Sat, 5 Jun 2010, Felipe Contreras wrote: > > How about instead of using full defconfigs, we use minimal ones and > let the rest be determined with defaults. I wouldn't mind that either, but there needs to be some way to check that they _are_ minimal. Which is more complicated than even SAT, afaik. So the reason I don't like the "minimal defconfig" notion is that a "regular defconfig" will work equally well, and lazy people will thus not bother to make it minimal (because it's work) and instead just pick the full config output. And we're all lazy. So gearing the process towards something that makes it easy for lazy cases to do the wrong thing is a bad thing. We also don't have any way to "source" these config files from each other, so there's no way from within such a config file to say "use the basic omap3 defaults an then just add this on top". You can do it by concatenating several such files manually from the Makefile or whatever script, of course, but then you end up with the files themselves not actually describing what they do. That's why I suggested the Kconfig format instead. It's the exact same idea, but it's a "before pre-processing" format that already supports including other files. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-05 14:39 ` Linus Torvalds @ 2010-06-05 16:39 ` Felipe Contreras 0 siblings, 0 replies; 133+ messages in thread From: Felipe Contreras @ 2010-06-05 16:39 UTC (permalink / raw) To: Linus Torvalds Cc: Tony Lindgren, Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, Vegard Nossum On Sat, Jun 5, 2010 at 5:39 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sat, 5 Jun 2010, Felipe Contreras wrote: >> >> How about instead of using full defconfigs, we use minimal ones and >> let the rest be determined with defaults. > > I wouldn't mind that either, but there needs to be some way to check that > they _are_ minimal. Which is more complicated than even SAT, afaik. I don't think so. The SAT should be able to come up with a minimal config for 'CONFIG_MACH_OMAP3_BEAGLE=y', and then a minimal config for whatever is in omap3_beagle_defconfig. The diff is either unnecessary, or the Kconfig files are missing some 'default y if whatever'. You fix the Kconfig files, and then use the resulting minimal config. > So the reason I don't like the "minimal defconfig" notion is that a > "regular defconfig" will work equally well, and lazy people will thus not > bother to make it minimal (because it's work) and instead just pick the > full config output. > > And we're all lazy. So gearing the process towards something that makes it > easy for lazy cases to do the wrong thing is a bad thing. Yes, that's why I lean toward the solution that creates an ideal config with the minimal effort: SAT with a single CONFIG_MACH_OMAP3_BEAGLE=y. Then you don't need defconfigs at all. > We also don't have any way to "source" these config files from each other, > so there's no way from within such a config file to say "use the basic > omap3 defaults an then just add this on top". You can do it by > concatenating several such files manually from the Makefile or whatever > script, of course, but then you end up with the files themselves not > actually describing what they do. I don't really see the big need for hierarchical configs. When you do 'make ARCH=arm' you are already including all the arm stuff, so there's no need for an ARM base config. Then you would need some platform stuff like OMAP3, but if you do CONFIG_ARCH_OMAP3=y, and there are proper 'default y if ARCH_OMAP3' in the Kconfigs, you don't need any base config either. The rest of the stuff is truly specific to the boards. If there's a need to include other configs, I'm sure we can come with markups to include them and have a parser script that generates the .config. > That's why I suggested the Kconfig format instead. It's the exact same > idea, but it's a "before pre-processing" format that already supports > including other files. Yes, although I don't like the format (it looks clearly designed for something else), it's another possibility. However, I don't think "allnoconfig" makes sense because that would ignore the default hints already present in Kconfig files. -- Felipe Contreras ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 20:31 ` Linus Torvalds 2010-06-03 21:17 ` Tony Lindgren @ 2010-06-03 21:48 ` Daniel Walker 2010-06-04 0:36 ` Paul Mackerras 2010-06-05 13:47 ` Felipe Contreras 3 siblings, 0 replies; 133+ messages in thread From: Daniel Walker @ 2010-06-03 21:48 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 2010-06-03 at 13:31 -0700, Linus Torvalds wrote: > and now you'd be able to basically generate a OMAP3EVM .config file by > just running "allnoconfig" on that Kconfig.omap3_evm file. But it would > only have to select the parts that are specific for the EVM platform, > because the generic OMAP3 support would be picked by the Kconfig.omap3 > file, which in turn would not have to worry about the generic ARM parts > etc. > > See? We could just alias commands so when the user runs "make ARCH=arm omap3_evm_defconfig" it would just do whatever this command does , "KBUILD_KCONFIG=arch/arm/configs/Kconfig.omap3_evm make allnoconfig" but those Kconfigs wouldn't be in "make menuconfig" it would just exist to generate the defconfigs, or the .config .. So Kconfig.omap3_evm basically becomes the defconfig. That doesn't seem un-reasonable. Although the solver to me seems more elegant and we're getting the solver for some other reasons it seems (unrelated to this defconfig issue). Daniel ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 20:31 ` Linus Torvalds 2010-06-03 21:17 ` Tony Lindgren 2010-06-03 21:48 ` Daniel Walker @ 2010-06-04 0:36 ` Paul Mackerras 2010-06-04 12:39 ` Grant Likely 2010-06-05 13:47 ` Felipe Contreras 3 siblings, 1 reply; 133+ messages in thread From: Paul Mackerras @ 2010-06-04 0:36 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 01:31:07PM -0700, Linus Torvalds wrote: > Now, the above is a _trivial_ one. And it's actually broken, because I > should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT). Seems to me that the brokenness of select is the main technical issue stopping us getting rid of the defconfigs. If there was a way to tell the Kconfig machinery "I want CONFIG_USB on, you figure out what has to be enabled for that to make sense" then it would all work. But that's a hard problem (and may possibly have multiple solutions). Paul. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-04 0:36 ` Paul Mackerras @ 2010-06-04 12:39 ` Grant Likely 0 siblings, 0 replies; 133+ messages in thread From: Grant Likely @ 2010-06-04 12:39 UTC (permalink / raw) To: Paul Mackerras Cc: Linus Torvalds, Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, Catalin Marinas On Thu, Jun 3, 2010 at 6:36 PM, Paul Mackerras <paulus@samba.org> wrote: > On Thu, Jun 03, 2010 at 01:31:07PM -0700, Linus Torvalds wrote: > >> Now, the above is a _trivial_ one. And it's actually broken, because I >> should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT). > > Seems to me that the brokenness of select is the main technical issue > stopping us getting rid of the defconfigs. If there was a way to tell > the Kconfig machinery "I want CONFIG_USB on, you figure out what has > to be enabled for that to make sense" then it would all work. But > that's a hard problem (and may possibly have multiple solutions). Yes, I think you're right. If select was 'smart', then the whole issue kind of goes away. But as you say, that is a hard problem. In the mean time, I'd be satisfied with a solution that punted out an error at configure time if select requirements did not get met. I should look at the patch Catalin posted. g. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 20:31 ` Linus Torvalds ` (2 preceding siblings ...) 2010-06-04 0:36 ` Paul Mackerras @ 2010-06-05 13:47 ` Felipe Contreras 3 siblings, 0 replies; 133+ messages in thread From: Felipe Contreras @ 2010-06-05 13:47 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 3, 2010 at 11:31 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, 3 Jun 2010, Linus Torvalds wrote: >> >> I apparently haven't explained myself enough, because what you keep on >> harping on is not something I consider acceptable. >> >> STD_CONFIG is pointless. It's pointless because the solution to what >> you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz >> file at all. > > To make this _really_ concrete, let me actually give you an example (but > broken and pointless) example Kconfig file, in order to _avoid_ having a > def_config file. > > I do it by generating it. Let's say that I want a x86 configuration that > has USB enabled. I can basically _ask_ the Kconfig machinery to generate > that with something like this: > > - create a "Mykconfig" file: > > config MYCONFIG > bool > default y > select USB > > source arch/x86/Kconfig > > and then I just do > > KBUILD_KCONFIG=Mykconfig make allnoconfig > > and look what appears in the .config file. In fact, do this: > > make allnoconfig > cp .config no-config > KBUILD_KCONFIG=Mykconfig make allnoconfig > cp .config my-config > diff -u no-config my-config > > to see the point of it all. > > Now, the above is a _trivial_ one. And it's actually broken, because I > should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT). And that's precisely the problem that his approach doesn't solve: dependencies. --- config MYCONFIG bool default y select MACH_OMAP3_BEAGLE source arch/arm/Kconfig --- Is the same as: --- source arch/arm/Kconfig --- With the SAT resolver it would be possible to have a .satconfig: CONFIG_MACH_OMAP3_BEAGLE=y And let the resolver figure everything out back from there. -- Felipe Contreras ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 20:09 ` Linus Torvalds 2010-06-03 20:31 ` Linus Torvalds @ 2010-06-03 20:34 ` Nicolas Pitre 1 sibling, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-06-03 20:34 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm [-- Attachment #1: Type: TEXT/PLAIN, Size: 1748 bytes --] On Thu, 3 Jun 2010, Linus Torvalds wrote: > > > On Thu, 3 Jun 2010, Russell King wrote: > > > > I already covered that in my (ignored) email where I brought up a > > "STD_CONFIG" config symbol, which could be disabled to turn off all > > these additional "select"s. > > I apparently haven't explained myself enough, because what you keep on > harping on is not something I consider acceptable. > > STD_CONFIG is pointless. It's pointless because the solution to what > you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz > file at all. Linus, I think somehow you and Russell are talking past each other. I must admit I don't exactly understand what your suggestion is all about. But I however think that Russell's suggestion makes tons of sense. Care to elaborate on what you dislike about it? What is this Kconfig.xyz you're talking about? How different is it from, say, arch/arm/mach-pxa/Kconfig? If you look into that file, you'll find a bunch of select's which are fundamentally needed for the given targets to boot. This file could be augmented with more conditional select's à la STD_CONFIG as Russell is advocating to actually provide defaults for the drivers that those targets should have by default. Nicolas > So when I suggest special Kconfig files, they are meant to just generate > the templates - ie they'd _generate_ what is currently the defconfig > files. You wouldn't _have_ to use them at all. Sure. a standard "make config" would still produce that .defconfig as usual. Only that you'd have to turn STD_CONFIG off to be offered the choice of enabling/disabling those drivers which are enabled by default otherwise, just like the "make foo_defconfig" is doing now. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 19:35 ` Daniel Walker 2010-06-03 19:45 ` Russell King @ 2010-06-03 20:05 ` Linus Torvalds 1 sibling, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-06-03 20:05 UTC (permalink / raw) To: Daniel Walker Cc: Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Daniel Walker wrote: > > If you did this for drivers, what about disabling a driver? If we used > "select" wouldn't that force all the drivers on without allowing it to > be unselected? Isn't that the point? If you have a specific platform, you don't want to pick them, you want to get the particular config file for it as a starting point. That's the _only_ reason to have those insane 177 defconfig files - because you want a _particular_ one. Once you have a particular one, you can always edit it with the regular configuration tools - including making tweaks by hand - as much as you want. So the only point of the thing would always be to get a result config file, one that you can then edit to your hearts content. And get it from a human-readable and writable description file, so that it would make sense to check it in to the kernel repository. Because right now, the current defconfig files DO NOT MAKE SENSE in the kernel repository. They are useless crud, and they hurt. So what I do _not_ want is the current crazy "give people these totally unreadable and unwritable raw config files". I want that extra step in between: something that allows you to _generate_ those idiotic files, but generate them from a reasonable human-editable template. And a Kconfig.xyz file _could_ be such a template. But anyway, I'm not actually all that excited about playing games with Kconfig files either. And I simply don't care. To me, a "git rm *defconfig" is perfectly acceptable. If you want to keep the current defconfig files, you can keep them on some random ARM site ("Here's a defconfig file for Nexus One"). So I'm actually perfectly fine with "no defconfig files at all, not even a template that can generate them". You can get the files from somewhere else where they don't hurt the kernel. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:53 ` Russell King 2010-06-03 18:56 ` Linus Torvalds @ 2010-06-06 3:28 ` david 1 sibling, 0 replies; 133+ messages in thread From: david @ 2010-06-06 3:28 UTC (permalink / raw) To: Russell King Cc: Linus Torvalds, Kevin Hilman, Daniel Walker, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Russell King wrote: > On Thu, Jun 03, 2010 at 11:18:05AM -0700, Linus Torvalds wrote: >> >> >> On Thu, 3 Jun 2010, Russell King wrote: >>> >>> Umm. I don't think you've actually looked at the Kconfig files if you're >>> writing this, because that's precisely what we already do. >> >> .. but if you do this _right_, then the defconfig files would be >> unnecessary. >> >> That's my point. If you are right, then I can remove the defconfig files >> entirely. Are you ready for that? > > Absolutely no way are we ready for that. > >> And if you aren't ready for that, then what was the point of your email? > > Linus, don't make this personal. > > The problem is NOT "what options which are found under the arch/arm tree > do I need". > > The problem is "what options throughout the rest of the kernel do I need > to result in a usable kernel". What do you define as useable? at two extremes: do you mean a kernel that fully supports the board and all it's features? do you mean a kernel that will compile and boot, but may not be able to talk to the outside world as it doesn't know about any I/O that the chip may have. I don't think that defconfig can work for the first case (every single system would hae it's own defconfig, which just doesn't scale) and I'm not sure the second is very useful (and it should be covered by the kconfig defaults) if you are looking for something in between, where do you draw the line? back when linux ran on x86 with IDE only, defconfig made a lot of sense, but that was because the hardware was very standardized, nowdays even in the x6 space there is enough variation that it's questionable how useful a defconfig is. What would be far better would be some tool that would take some hardware defintition (either autodetecting from a currenlty running system on x86, or from the device_tree stuff that's being worked on for other architectures) and create a kernel config from that that would fully support the hardware detected. David Lang > No amount of reorganising the Kconfig files into a heirarchial manner > (which they already are) helps. Not one bit. Because they already are. > That's not where the problem is. > > For instance, if I have platform A, I know it has an RTC. How do I know > which of the 37 RTC drivers the kernel configuration presents me with to > select? Am I really expected to open up the platform and read the > device numbers off all the chips (some of which being surface mount are > abbreviated) and work out that it's a TWL4030 RTC that I should be using? > > That's just one instance - and there's probably many more just like that. > Just look at "multifunction drivers" for another case in point. How the > hell do I know what multifunction driver is appropriate for a platform? > > Ditto "Power supply support". > > The list goes endlessly on. All those things I've mentioned are all > _outside_ of arch/arm. That's where the _real_ problem is. Solve that > problem so that it's easier for people to configure the kernel, and then > we don't need the multitude defconfig files. > > That's the problem which the defconfigs are solving today. > > ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:10 ` Russell King 2010-06-03 18:18 ` Linus Torvalds @ 2010-06-03 18:20 ` Daniel Walker 2010-06-03 18:21 ` Linus Torvalds 2010-06-03 18:41 ` Russell King 1 sibling, 2 replies; 133+ messages in thread From: Daniel Walker @ 2010-06-03 18:20 UTC (permalink / raw) To: Russell King Cc: Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 2010-06-03 at 19:10 +0100, Russell King wrote: > config STD_CONFIG > bool "Enable me to generate a standard configuration for your platform" > > and then have platforms conditionally select everything that's > appropriate for their use. That provides a way to avoid the ages old > issue of select forcing options on, but the user still being presented > with the option and being told the only possible value for it is 'y'. > > And yes, it _is_ necessary - because if you want to turn off something > on the platform - eg, you're not using MMC and MMC fails to build - > you can still end up with a working configuration at the end of the > day. Check out the SAT solver link I quoted in the prior email.. That sounds like a really interesting solution. The defconfigs would ultimately hold just what's unique to a given board, then the solver would figure out what to else to enable just from those unique properties. So we would still have defconfigs , but they would not have loads of duplication like they do now. I don't see how we can do without defconfigs altogether tho. I mean , if you want to run a Beagle board or a Nexus one we can't just give the users a slim ARM config and let them troll through 1000's of drivers trying to find just those ones that work on their given board. Daniel ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:20 ` Daniel Walker @ 2010-06-03 18:21 ` Linus Torvalds 2010-06-03 18:30 ` Al Viro ` (2 more replies) 2010-06-03 18:41 ` Russell King 1 sibling, 3 replies; 133+ messages in thread From: Linus Torvalds @ 2010-06-03 18:21 UTC (permalink / raw) To: Daniel Walker Cc: Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Daniel Walker wrote: > > I don't see how we can do without defconfigs altogether tho. I mean , if > you want to run a Beagle board or a Nexus one we can't just give the > users a slim ARM config and let them troll through 1000's of drivers > trying to find just those ones that work on their given board. Well, you also don't need the full defconfig's with the kernel. Right now they are just noise. They actually _hide_ things, because diffstat (and dirstat) information becomes pointless, and the diffs become totally unreadable by any human (trust me - when the choice is between "search for next relevant diff" or "blast it, I can't be bothered with walking through this crap", quite often the choice is the latter). So they are an actual burden on real development. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:21 ` Linus Torvalds @ 2010-06-03 18:30 ` Al Viro 2010-06-03 19:26 ` Paul Mundt 2010-06-14 8:32 ` Uwe Kleine-König 2 siblings, 0 replies; 133+ messages in thread From: Al Viro @ 2010-06-03 18:30 UTC (permalink / raw) To: Linus Torvalds Cc: Daniel Walker, Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote: > > > On Thu, 3 Jun 2010, Daniel Walker wrote: > > > > I don't see how we can do without defconfigs altogether tho. I mean , if > > you want to run a Beagle board or a Nexus one we can't just give the > > users a slim ARM config and let them troll through 1000's of drivers > > trying to find just those ones that work on their given board. > > Well, you also don't need the full defconfig's with the kernel. > > Right now they are just noise. They actually _hide_ things, because > diffstat (and dirstat) information becomes pointless, and the diffs become > totally unreadable by any human (trust me - when the choice is between > "search for next relevant diff" or "blast it, I can't be bothered with > walking through this crap", quite often the choice is the latter). > > So they are an actual burden on real development. BTW, can't we switch to processing them with cpp? That'd cut down on the churn big way, AFAICS, not to mention reducing the odds of missing some of them on such changes, etc. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:21 ` Linus Torvalds 2010-06-03 18:30 ` Al Viro @ 2010-06-03 19:26 ` Paul Mundt 2010-06-14 8:32 ` Uwe Kleine-König 2 siblings, 0 replies; 133+ messages in thread From: Paul Mundt @ 2010-06-03 19:26 UTC (permalink / raw) To: Linus Torvalds Cc: Daniel Walker, Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote: > On Thu, 3 Jun 2010, Daniel Walker wrote: > > I don't see how we can do without defconfigs altogether tho. I mean , if > > you want to run a Beagle board or a Nexus one we can't just give the > > users a slim ARM config and let them troll through 1000's of drivers > > trying to find just those ones that work on their given board. > > Well, you also don't need the full defconfig's with the kernel. > That's true. We already have things like KCONFIG_ALLCONFIG for these purposes, and that's primarily what I use for buildig bootable randconfigs for specific board/CPU combinations on SH. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:21 ` Linus Torvalds @ 2010-06-14 8:32 ` Uwe Kleine-König 2010-06-03 19:26 ` Paul Mundt 2010-06-14 8:32 ` Uwe Kleine-König 2 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-06-14 8:32 UTC (permalink / raw) To: Linus Torvalds Cc: Daniel Walker, Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel Hello, [Added linux-arm-kernel ML to Cc, note that it's moderated for non-subscribers.] On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote: > > > On Thu, 3 Jun 2010, Daniel Walker wrote: > > > > I don't see how we can do without defconfigs altogether tho. I mean , if > > you want to run a Beagle board or a Nexus one we can't just give the > > users a slim ARM config and let them troll through 1000's of drivers > > trying to find just those ones that work on their given board. > > Well, you also don't need the full defconfig's with the kernel. > > Right now they are just noise. They actually _hide_ things, because > diffstat (and dirstat) information becomes pointless, and the diffs become > totally unreadable by any human (trust me - when the choice is between > "search for next relevant diff" or "blast it, I can't be bothered with > walking through this crap", quite often the choice is the latter). I wrote a script that throws out all unneeded lines in all arm defconfigs that don't influence the resulting .config for .34 and .35-rc1 and compared .34<->.35-rc with .34-reduced<->.35-rc1-reduced. Here are the results: $ git diff --dirstat v2.6.34 v2.6.35-rc1 arch/arm 11.8% arch/arm/configs/ 10.0% arch/arm/mach-msm/ 10.8% arch/arm/mach-omap2/ 4.8% arch/arm/mach-pxa/ 4.5% arch/arm/mach-s5pc100/ 3.3% arch/arm/mach-s5pv210/ 4.4% arch/arm/mach-spear3xx/ 3.1% arch/arm/mach-ux500/ 5.1% arch/arm/plat-s5pc1xx/ 3.1% arch/arm/plat-samsung/ 38.2% arch/arm/ $ git diff --dirstat arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm 3.1% arch/arm/mach-davinci/ 11.3% arch/arm/mach-msm/ 12.2% arch/arm/mach-omap2/ 5.4% arch/arm/mach-pxa/ 5.1% arch/arm/mach-s5pc100/ 3.7% arch/arm/mach-s5pv210/ 5.0% arch/arm/mach-spear3xx/ 3.5% arch/arm/mach-ux500/ 5.8% arch/arm/plat-s5pc1xx/ 3.5% arch/arm/plat-samsung/ 40.9% arch/arm/ $ git diff --dirstat=0 arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm | grep config 1.1% arch/arm/configs/ $ git diff --shortstat v2.6.35-rc1 arm/defconfig/reduced-v2.6.35-rc1 177 files changed, 652 insertions(+), 194157 deletions(-) (The insertions above are only moved lines I think, I didn't check them all.) The branches arm/defconfig/reduced-v2.6.34 and arm/defconfig/reduced-v2.6.35-rc1 are available at my repo at git://git.pengutronix.de/git/ukl/linux-2.6.git . (There is a gitweb at http://git.pengutronix.de/?p=ukl/linux-2.6.git) So maintaining these minimal defconfigs would have reduced the defconfig noise from 11.8% down to 1.1%. And probably it could be considerably reduced further with constructs like: config HAVE_MTD_NAND_MXC bool config MTD_NAND_MXC tristate "MXC NAND support" ... default m if HAVE_MTD_NAND_MXC help ... ... config MACH_MX27ADS ... select HAVE_MTD_NAND_MXC . Compared with selecting everything in Kconfig files this approach allows further tweaking of a config. (E.g. "I have a mx27ads machine, but I don't need nand support.") Compared with the SAT-Solver it's an idea that works today. One downside of this approach (when done with my script only) is that too much is removed. E.g. in mx3_defconfig CONFIG_ARCH_MX3 is removed. This is OK from a logical POV but then changing the default of the corresponding choice (and I intend to do that in the near future) would break this defconfig. I can share my script and I'm willing to support maintaining the minimality of the defconfig files if they are an acceptable (maybe intermediate) step for Linus. Together with the efforts to reduce the number of defconfigs as thought about in other mails of this thread the situation should become quite better for Linus. (I'm currently working on merging support for all Freescale SoCs into a single mach- directory and so merge mx1_defconfig, mx21_defconfig, mx27_defconfig, mx31pdk_defconfig, mx3_defconfig and mx51_defconfig.) Linus: I would really appreciate if you wouldn't remove all (or nearly all) defconfig files. I think you would force a quicker solution to this problem, but during that time the ARM community would loose compile coverage. Thoughts on this? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-06-14 8:32 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-06-14 8:32 UTC (permalink / raw) To: linux-arm-kernel Hello, [Added linux-arm-kernel ML to Cc, note that it's moderated for non-subscribers.] On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote: > > > On Thu, 3 Jun 2010, Daniel Walker wrote: > > > > I don't see how we can do without defconfigs altogether tho. I mean , if > > you want to run a Beagle board or a Nexus one we can't just give the > > users a slim ARM config and let them troll through 1000's of drivers > > trying to find just those ones that work on their given board. > > Well, you also don't need the full defconfig's with the kernel. > > Right now they are just noise. They actually _hide_ things, because > diffstat (and dirstat) information becomes pointless, and the diffs become > totally unreadable by any human (trust me - when the choice is between > "search for next relevant diff" or "blast it, I can't be bothered with > walking through this crap", quite often the choice is the latter). I wrote a script that throws out all unneeded lines in all arm defconfigs that don't influence the resulting .config for .34 and .35-rc1 and compared .34<->.35-rc with .34-reduced<->.35-rc1-reduced. Here are the results: $ git diff --dirstat v2.6.34 v2.6.35-rc1 arch/arm 11.8% arch/arm/configs/ 10.0% arch/arm/mach-msm/ 10.8% arch/arm/mach-omap2/ 4.8% arch/arm/mach-pxa/ 4.5% arch/arm/mach-s5pc100/ 3.3% arch/arm/mach-s5pv210/ 4.4% arch/arm/mach-spear3xx/ 3.1% arch/arm/mach-ux500/ 5.1% arch/arm/plat-s5pc1xx/ 3.1% arch/arm/plat-samsung/ 38.2% arch/arm/ $ git diff --dirstat arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm 3.1% arch/arm/mach-davinci/ 11.3% arch/arm/mach-msm/ 12.2% arch/arm/mach-omap2/ 5.4% arch/arm/mach-pxa/ 5.1% arch/arm/mach-s5pc100/ 3.7% arch/arm/mach-s5pv210/ 5.0% arch/arm/mach-spear3xx/ 3.5% arch/arm/mach-ux500/ 5.8% arch/arm/plat-s5pc1xx/ 3.5% arch/arm/plat-samsung/ 40.9% arch/arm/ $ git diff --dirstat=0 arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm | grep config 1.1% arch/arm/configs/ $ git diff --shortstat v2.6.35-rc1 arm/defconfig/reduced-v2.6.35-rc1 177 files changed, 652 insertions(+), 194157 deletions(-) (The insertions above are only moved lines I think, I didn't check them all.) The branches arm/defconfig/reduced-v2.6.34 and arm/defconfig/reduced-v2.6.35-rc1 are available at my repo at git://git.pengutronix.de/git/ukl/linux-2.6.git . (There is a gitweb at http://git.pengutronix.de/?p=ukl/linux-2.6.git) So maintaining these minimal defconfigs would have reduced the defconfig noise from 11.8% down to 1.1%. And probably it could be considerably reduced further with constructs like: config HAVE_MTD_NAND_MXC bool config MTD_NAND_MXC tristate "MXC NAND support" ... default m if HAVE_MTD_NAND_MXC help ... ... config MACH_MX27ADS ... select HAVE_MTD_NAND_MXC . Compared with selecting everything in Kconfig files this approach allows further tweaking of a config. (E.g. "I have a mx27ads machine, but I don't need nand support.") Compared with the SAT-Solver it's an idea that works today. One downside of this approach (when done with my script only) is that too much is removed. E.g. in mx3_defconfig CONFIG_ARCH_MX3 is removed. This is OK from a logical POV but then changing the default of the corresponding choice (and I intend to do that in the near future) would break this defconfig. I can share my script and I'm willing to support maintaining the minimality of the defconfig files if they are an acceptable (maybe intermediate) step for Linus. Together with the efforts to reduce the number of defconfigs as thought about in other mails of this thread the situation should become quite better for Linus. (I'm currently working on merging support for all Freescale SoCs into a single mach- directory and so merge mx1_defconfig, mx21_defconfig, mx27_defconfig, mx31pdk_defconfig, mx3_defconfig and mx51_defconfig.) Linus: I would really appreciate if you wouldn't remove all (or nearly all) defconfig files. I think you would force a quicker solution to this problem, but during that time the ARM community would loose compile coverage. Thoughts on this? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-14 8:32 ` Uwe Kleine-König @ 2010-06-30 10:40 ` Uwe Kleine-König -1 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-06-30 10:40 UTC (permalink / raw) To: Linus Torvalds Cc: Daniel Walker, Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre Hi Linus, I think my mail hit your inbox during your vacation. As this is quite important for the ARM people and there isn't much time left, can you please comment? Thanks in advance Uwe On Mon, Jun 14, 2010 at 10:32:14AM +0200, Uwe Kleine-König wrote: > Hello, > > [Added linux-arm-kernel ML to Cc, note that it's moderated for > non-subscribers.] > > On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote: > > > > > > On Thu, 3 Jun 2010, Daniel Walker wrote: > > > > > > I don't see how we can do without defconfigs altogether tho. I mean , if > > > you want to run a Beagle board or a Nexus one we can't just give the > > > users a slim ARM config and let them troll through 1000's of drivers > > > trying to find just those ones that work on their given board. > > > > Well, you also don't need the full defconfig's with the kernel. > > > > Right now they are just noise. They actually _hide_ things, because > > diffstat (and dirstat) information becomes pointless, and the diffs become > > totally unreadable by any human (trust me - when the choice is between > > "search for next relevant diff" or "blast it, I can't be bothered with > > walking through this crap", quite often the choice is the latter). > I wrote a script that throws out all unneeded lines in all arm > defconfigs that don't influence the resulting .config for .34 and > .35-rc1 and compared .34<->.35-rc with .34-reduced<->.35-rc1-reduced. > > Here are the results: > > $ git diff --dirstat v2.6.34 v2.6.35-rc1 arch/arm > 11.8% arch/arm/configs/ > 10.0% arch/arm/mach-msm/ > 10.8% arch/arm/mach-omap2/ > 4.8% arch/arm/mach-pxa/ > 4.5% arch/arm/mach-s5pc100/ > 3.3% arch/arm/mach-s5pv210/ > 4.4% arch/arm/mach-spear3xx/ > 3.1% arch/arm/mach-ux500/ > 5.1% arch/arm/plat-s5pc1xx/ > 3.1% arch/arm/plat-samsung/ > 38.2% arch/arm/ > > $ git diff --dirstat arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm > 3.1% arch/arm/mach-davinci/ > 11.3% arch/arm/mach-msm/ > 12.2% arch/arm/mach-omap2/ > 5.4% arch/arm/mach-pxa/ > 5.1% arch/arm/mach-s5pc100/ > 3.7% arch/arm/mach-s5pv210/ > 5.0% arch/arm/mach-spear3xx/ > 3.5% arch/arm/mach-ux500/ > 5.8% arch/arm/plat-s5pc1xx/ > 3.5% arch/arm/plat-samsung/ > 40.9% arch/arm/ > > $ git diff --dirstat=0 arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm | grep config > 1.1% arch/arm/configs/ > > $ git diff --shortstat v2.6.35-rc1 arm/defconfig/reduced-v2.6.35-rc1 > 177 files changed, 652 insertions(+), 194157 deletions(-) > > (The insertions above are only moved lines I think, I didn't check them > all.) > > The branches arm/defconfig/reduced-v2.6.34 and > arm/defconfig/reduced-v2.6.35-rc1 are available at my repo at > git://git.pengutronix.de/git/ukl/linux-2.6.git . (There is a gitweb at > http://git.pengutronix.de/?p=ukl/linux-2.6.git) > > So maintaining these minimal defconfigs would have reduced the defconfig > noise from 11.8% down to 1.1%. And probably it could be considerably > reduced further with constructs like: > > config HAVE_MTD_NAND_MXC > bool > > config MTD_NAND_MXC > tristate "MXC NAND support" > ... > default m if HAVE_MTD_NAND_MXC > help > ... > > ... > config MACH_MX27ADS > ... > select HAVE_MTD_NAND_MXC > > . Compared with selecting everything in Kconfig files this approach > allows further tweaking of a config. (E.g. "I have a mx27ads machine, > but I don't need nand support.") Compared with the SAT-Solver it's an > idea that works today. > > One downside of this approach (when done with my script only) is that > too much is removed. E.g. in mx3_defconfig CONFIG_ARCH_MX3 is removed. > This is OK from a logical POV but then changing the default of the > corresponding choice (and I intend to do that in the near future) would > break this defconfig. > > I can share my script and I'm willing to support maintaining the > minimality of the defconfig files if they are an acceptable (maybe > intermediate) step for Linus. > > Together with the efforts to reduce the number of defconfigs as thought > about in other mails of this thread the situation should become quite > better for Linus. (I'm currently working on merging support for all > Freescale SoCs into a single mach- directory and so merge mx1_defconfig, > mx21_defconfig, mx27_defconfig, mx31pdk_defconfig, mx3_defconfig and > mx51_defconfig.) > > Linus: I would really appreciate if you wouldn't remove all (or nearly > all) defconfig files. I think you would force a quicker solution to > this problem, but during that time the ARM community would loose compile > coverage. > > Thoughts on this? > > Best regards > Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-06-30 10:40 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-06-30 10:40 UTC (permalink / raw) To: linux-arm-kernel Hi Linus, I think my mail hit your inbox during your vacation. As this is quite important for the ARM people and there isn't much time left, can you please comment? Thanks in advance Uwe On Mon, Jun 14, 2010 at 10:32:14AM +0200, Uwe Kleine-K?nig wrote: > Hello, > > [Added linux-arm-kernel ML to Cc, note that it's moderated for > non-subscribers.] > > On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote: > > > > > > On Thu, 3 Jun 2010, Daniel Walker wrote: > > > > > > I don't see how we can do without defconfigs altogether tho. I mean , if > > > you want to run a Beagle board or a Nexus one we can't just give the > > > users a slim ARM config and let them troll through 1000's of drivers > > > trying to find just those ones that work on their given board. > > > > Well, you also don't need the full defconfig's with the kernel. > > > > Right now they are just noise. They actually _hide_ things, because > > diffstat (and dirstat) information becomes pointless, and the diffs become > > totally unreadable by any human (trust me - when the choice is between > > "search for next relevant diff" or "blast it, I can't be bothered with > > walking through this crap", quite often the choice is the latter). > I wrote a script that throws out all unneeded lines in all arm > defconfigs that don't influence the resulting .config for .34 and > .35-rc1 and compared .34<->.35-rc with .34-reduced<->.35-rc1-reduced. > > Here are the results: > > $ git diff --dirstat v2.6.34 v2.6.35-rc1 arch/arm > 11.8% arch/arm/configs/ > 10.0% arch/arm/mach-msm/ > 10.8% arch/arm/mach-omap2/ > 4.8% arch/arm/mach-pxa/ > 4.5% arch/arm/mach-s5pc100/ > 3.3% arch/arm/mach-s5pv210/ > 4.4% arch/arm/mach-spear3xx/ > 3.1% arch/arm/mach-ux500/ > 5.1% arch/arm/plat-s5pc1xx/ > 3.1% arch/arm/plat-samsung/ > 38.2% arch/arm/ > > $ git diff --dirstat arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm > 3.1% arch/arm/mach-davinci/ > 11.3% arch/arm/mach-msm/ > 12.2% arch/arm/mach-omap2/ > 5.4% arch/arm/mach-pxa/ > 5.1% arch/arm/mach-s5pc100/ > 3.7% arch/arm/mach-s5pv210/ > 5.0% arch/arm/mach-spear3xx/ > 3.5% arch/arm/mach-ux500/ > 5.8% arch/arm/plat-s5pc1xx/ > 3.5% arch/arm/plat-samsung/ > 40.9% arch/arm/ > > $ git diff --dirstat=0 arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm | grep config > 1.1% arch/arm/configs/ > > $ git diff --shortstat v2.6.35-rc1 arm/defconfig/reduced-v2.6.35-rc1 > 177 files changed, 652 insertions(+), 194157 deletions(-) > > (The insertions above are only moved lines I think, I didn't check them > all.) > > The branches arm/defconfig/reduced-v2.6.34 and > arm/defconfig/reduced-v2.6.35-rc1 are available at my repo at > git://git.pengutronix.de/git/ukl/linux-2.6.git . (There is a gitweb at > http://git.pengutronix.de/?p=ukl/linux-2.6.git) > > So maintaining these minimal defconfigs would have reduced the defconfig > noise from 11.8% down to 1.1%. And probably it could be considerably > reduced further with constructs like: > > config HAVE_MTD_NAND_MXC > bool > > config MTD_NAND_MXC > tristate "MXC NAND support" > ... > default m if HAVE_MTD_NAND_MXC > help > ... > > ... > config MACH_MX27ADS > ... > select HAVE_MTD_NAND_MXC > > . Compared with selecting everything in Kconfig files this approach > allows further tweaking of a config. (E.g. "I have a mx27ads machine, > but I don't need nand support.") Compared with the SAT-Solver it's an > idea that works today. > > One downside of this approach (when done with my script only) is that > too much is removed. E.g. in mx3_defconfig CONFIG_ARCH_MX3 is removed. > This is OK from a logical POV but then changing the default of the > corresponding choice (and I intend to do that in the near future) would > break this defconfig. > > I can share my script and I'm willing to support maintaining the > minimality of the defconfig files if they are an acceptable (maybe > intermediate) step for Linus. > > Together with the efforts to reduce the number of defconfigs as thought > about in other mails of this thread the situation should become quite > better for Linus. (I'm currently working on merging support for all > Freescale SoCs into a single mach- directory and so merge mx1_defconfig, > mx21_defconfig, mx27_defconfig, mx31pdk_defconfig, mx3_defconfig and > mx51_defconfig.) > > Linus: I would really appreciate if you wouldn't remove all (or nearly > all) defconfig files. I think you would force a quicker solution to > this problem, but during that time the ARM community would loose compile > coverage. > > Thoughts on this? > > Best regards > Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-30 10:40 ` Uwe Kleine-König @ 2010-07-12 15:55 ` Uwe Kleine-König -1 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-12 15:55 UTC (permalink / raw) To: Linus Torvalds Cc: Daniel Walker, Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre Hi Linus, On Wed, Jun 30, 2010 at 12:40:43PM +0200, Uwe Kleine-König wrote: > I think my mail hit your inbox during your vacation. As this is quite > important for the ARM people and there isn't much time left, can you > please comment? As you havn't replied up to now I wonder if that just means that you still plan to remove all defconfig files or if you are just busy doing other things. Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 15:55 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-12 15:55 UTC (permalink / raw) To: linux-arm-kernel Hi Linus, On Wed, Jun 30, 2010 at 12:40:43PM +0200, Uwe Kleine-K?nig wrote: > I think my mail hit your inbox during your vacation. As this is quite > important for the ARM people and there isn't much time left, can you > please comment? As you havn't replied up to now I wonder if that just means that you still plan to remove all defconfig files or if you are just busy doing other things. Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 15:55 ` Uwe Kleine-König (?) @ 2010-07-12 16:51 ` Linus Torvalds -1 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 16:51 UTC (permalink / raw) To: Uwe Kleine-König Cc: Daniel Walker, Russell King, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre 2010/7/12 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: > > As you havn't replied up to now I wonder if that just means that you > still plan to remove all defconfig files or if you are just busy doing > other things. The reason I haven't replied is that (a) I don't think this really "solves" the issue, in that the resulting files still aren't human-readable, and as such I suspect it doesn't solve the problem in the long run: people will continue to just run "make config" and then copy the resulting .config file as a defconfig file. and (b) even if ARM were to go this way, and run the scripts to minimize the defconfig files, that's not something _I_ would do. If I get tired of seeing the insane pull requests where 90% of the crap is just defconfig noise, then _my_ solution will be to remove the crap because I simply am never going to be the person who maintains those defconfig files. See? Especially the "(b)" part is relevant - I am simply not going to be the person who tries to clean up after other people sh*tting all over their trees with defconfig files. If I do something, it will be total surgery, ie "keep your damn broken defconfig files somewhere else than in my tree - I'm tired of your stupidities". It will not be "I'll be your mother and clean up your room every day after you made a mess". So if the ARM people decide that your script is a good way to clean up the mess, I might be happy with that. But that would require that they NEVER EVER try to push me a update that contains an un-cleaned-up defconfig file. If they do, and the defconfig files end up showing up big in git history, then the approach has failed. See? The reason I'm not replying to your approach is that it's simply not for me to do so (and no, I don't think it's maintainable, but I haven't tried it, so..) Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 16:51 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 16:51 UTC (permalink / raw) To: linux-arm-kernel 2010/7/12 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>: > > As you havn't replied up to now I wonder if that just means that you > still plan to remove all defconfig files or if you are just busy doing > other things. The reason I haven't replied is that (a) I don't think this really "solves" the issue, in that the resulting files still aren't human-readable, and as such I suspect it doesn't solve the problem in the long run: people will continue to just run "make config" and then copy the resulting .config file as a defconfig file. and (b) even if ARM were to go this way, and run the scripts to minimize the defconfig files, that's not something _I_ would do. If I get tired of seeing the insane pull requests where 90% of the crap is just defconfig noise, then _my_ solution will be to remove the crap because I simply am never going to be the person who maintains those defconfig files. See? Especially the "(b)" part is relevant - I am simply not going to be the person who tries to clean up after other people sh*tting all over their trees with defconfig files. If I do something, it will be total surgery, ie "keep your damn broken defconfig files somewhere else than in my tree - I'm tired of your stupidities". It will not be "I'll be your mother and clean up your room every day after you made a mess". So if the ARM people decide that your script is a good way to clean up the mess, I might be happy with that. But that would require that they NEVER EVER try to push me a update that contains an un-cleaned-up defconfig file. If they do, and the defconfig files end up showing up big in git history, then the approach has failed. See? The reason I'm not replying to your approach is that it's simply not for me to do so (and no, I don't think it's maintainable, but I haven't tried it, so..) Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-12 16:51 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 16:51 UTC (permalink / raw) To: Uwe Kleine-König Cc: Daniel Walker, Nicolas Pitre, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, Grant Likely, linux-omap, linux-arm-kernel, Eric Miao, Russell King 2010/7/12 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: > > As you havn't replied up to now I wonder if that just means that you > still plan to remove all defconfig files or if you are just busy doing > other things. The reason I haven't replied is that (a) I don't think this really "solves" the issue, in that the resulting files still aren't human-readable, and as such I suspect it doesn't solve the problem in the long run: people will continue to just run "make config" and then copy the resulting .config file as a defconfig file. and (b) even if ARM were to go this way, and run the scripts to minimize the defconfig files, that's not something _I_ would do. If I get tired of seeing the insane pull requests where 90% of the crap is just defconfig noise, then _my_ solution will be to remove the crap because I simply am never going to be the person who maintains those defconfig files. See? Especially the "(b)" part is relevant - I am simply not going to be the person who tries to clean up after other people sh*tting all over their trees with defconfig files. If I do something, it will be total surgery, ie "keep your damn broken defconfig files somewhere else than in my tree - I'm tired of your stupidities". It will not be "I'll be your mother and clean up your room every day after you made a mess". So if the ARM people decide that your script is a good way to clean up the mess, I might be happy with that. But that would require that they NEVER EVER try to push me a update that contains an un-cleaned-up defconfig file. If they do, and the defconfig files end up showing up big in git history, then the approach has failed. See? The reason I'm not replying to your approach is that it's simply not for me to do so (and no, I don't think it's maintainable, but I haven't tried it, so..) Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 16:51 ` Linus Torvalds @ 2010-07-12 17:32 ` Russell King - ARM Linux -1 siblings, 0 replies; 133+ messages in thread From: Russell King - ARM Linux @ 2010-07-12 17:32 UTC (permalink / raw) To: Linus Torvalds Cc: Uwe Kleine-König, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Mon, Jul 12, 2010 at 09:51:47AM -0700, Linus Torvalds wrote: > So if the ARM people decide that your script is a good way to clean up > the mess, I might be happy with that. But that would require that they > NEVER EVER try to push me a update that contains an un-cleaned-up > defconfig file. Does this mean that you aren't going to delete all the defconfigs during the next merge window if we come up with an alternative solution to yours? When you brought up the problem you seemed absolutely convinced that nothing except your solution was going to be acceptable. ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 17:32 ` Russell King - ARM Linux 0 siblings, 0 replies; 133+ messages in thread From: Russell King - ARM Linux @ 2010-07-12 17:32 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 09:51:47AM -0700, Linus Torvalds wrote: > So if the ARM people decide that your script is a good way to clean up > the mess, I might be happy with that. But that would require that they > NEVER EVER try to push me a update that contains an un-cleaned-up > defconfig file. Does this mean that you aren't going to delete all the defconfigs during the next merge window if we come up with an alternative solution to yours? When you brought up the problem you seemed absolutely convinced that nothing except your solution was going to be acceptable. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 17:32 ` Russell King - ARM Linux (?) @ 2010-07-12 17:40 ` Linus Torvalds -1 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 17:40 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Uwe Kleine-König, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > > When you brought up the problem you seemed absolutely convinced > that nothing except your solution was going to be acceptable. That's not true. What's true is that you didn't seem to _understand_ my solution, so I tried to push the understanding of it. There are always other solutions. I seriously doubt that Uwe's is a maintainable one. That said, even a one-time "reduce the size of that stinking pile of sh*t" is probably better than nothing. I hope you at least do agree that the current situation is a steaming pile of sh*t. And yes, I _will_ remove the crap, both from POWER and ARM, unless I see some serious tries at fixing it. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 17:40 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 17:40 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > > When you brought up the problem you seemed absolutely convinced > that nothing except your solution was going to be acceptable. That's not true. What's true is that you didn't seem to _understand_ my solution, so I tried to push the understanding of it. There are always other solutions. I seriously doubt that Uwe's is a maintainable one. That said, even a one-time "reduce the size of that stinking pile of sh*t" is probably better than nothing. I hope you at least do agree that the current situation is a steaming pile of sh*t. And yes, I _will_ remove the crap, both from POWER and ARM, unless I see some serious tries at fixing it. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-12 17:40 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 17:40 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Daniel Walker, Nicolas Pitre, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, Grant Likely, linux-omap, Uwe Kleine-König, Eric Miao, linux-arm-kernel On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > > When you brought up the problem you seemed absolutely convinced > that nothing except your solution was going to be acceptable. That's not true. What's true is that you didn't seem to _understand_ my solution, so I tried to push the understanding of it. There are always other solutions. I seriously doubt that Uwe's is a maintainable one. That said, even a one-time "reduce the size of that stinking pile of sh*t" is probably better than nothing. I hope you at least do agree that the current situation is a steaming pile of sh*t. And yes, I _will_ remove the crap, both from POWER and ARM, unless I see some serious tries at fixing it. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 17:40 ` Linus Torvalds (?) @ 2010-07-12 18:50 ` Uwe Kleine-König -1 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-12 18:50 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre Hello Linus, On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > > When you brought up the problem you seemed absolutely convinced > > that nothing except your solution was going to be acceptable. > > That's not true. What's true is that you didn't seem to _understand_ > my solution, so I tried to push the understanding of it. > > There are always other solutions. I seriously doubt that Uwe's is a > maintainable one. That said, even a one-time "reduce the size of that > stinking pile of sh*t" is probably better than nothing. > > I hope you at least do agree that the current situation is a steaming > pile of sh*t. And yes, I _will_ remove the crap, both from POWER and > ARM, unless I see some serious tries at fixing it. I'm willing to try my solution, some others on the linux-arm-kernel lists considered it worth trying, too. Feel free to pull my tree[1]. Russell refused to take defconfig changes for a while now, so I don't expect merge problems if you do. If it helps the powerpc people I can reduce their defconfigs, too. Best regards Uwe [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 Uwe Kleine-König (1): ARM: reduce defconfigs arch/arm/configs/acs5k_defconfig | 1146 -------------- arch/arm/configs/acs5k_tiny_defconfig | 860 ---------- arch/arm/configs/afeb9260_defconfig | 1157 +-------------- arch/arm/configs/am200epdkit_defconfig | 1044 +------------ arch/arm/configs/am3517_evm_defconfig | 1250 --------------- arch/arm/configs/ams_delta_defconfig | 1224 +-------------- arch/arm/configs/ap4evb_defconfig | 722 --------- arch/arm/configs/assabet_defconfig | 862 +---------- arch/arm/configs/at572d940hfek_defconfig | 1318 +--------------- arch/arm/configs/at91cap9adk_defconfig | 1107 +------------- arch/arm/configs/at91rm9200dk_defconfig | 955 +----------- arch/arm/configs/at91rm9200ek_defconfig | 942 +----------- arch/arm/configs/at91sam9260ek_defconfig | 958 +----------- arch/arm/configs/at91sam9261ek_defconfig | 1087 +------------- arch/arm/configs/at91sam9263ek_defconfig | 1103 +------------- arch/arm/configs/at91sam9g20ek_defconfig | 1049 +------------ arch/arm/configs/at91sam9rlek_defconfig | 864 +---------- arch/arm/configs/ateb9200_defconfig | 1222 +-------------- arch/arm/configs/badge4_defconfig | 1178 +-------------- arch/arm/configs/bcmring_defconfig | 721 --------- arch/arm/configs/cam60_defconfig | 1089 +------------- arch/arm/configs/carmeva_defconfig | 696 +-------- arch/arm/configs/cerfcube_defconfig | 851 +---------- arch/arm/configs/cm_t35_defconfig | 1577 +------------------ arch/arm/configs/cm_x2xx_defconfig | 1774 +--------------------- arch/arm/configs/cm_x300_defconfig | 1565 ------------------ arch/arm/configs/cns3420vb_defconfig | 759 --------- arch/arm/configs/colibri_pxa270_defconfig | 1556 ------------------ arch/arm/configs/colibri_pxa300_defconfig | 1082 ------------- arch/arm/configs/collie_defconfig | 887 +---------- arch/arm/configs/corgi_defconfig | 1621 +------------------- arch/arm/configs/cpu9260_defconfig | 1225 +-------------- arch/arm/configs/cpu9g20_defconfig | 1215 +-------------- arch/arm/configs/cpuat91_defconfig | 1207 +-------------- arch/arm/configs/csb337_defconfig | 1113 +------------- arch/arm/configs/csb637_defconfig | 1124 +------------- arch/arm/configs/da8xx_omapl_defconfig | 1205 -------------- arch/arm/configs/davinci_all_defconfig | 1641 ------------------- arch/arm/configs/devkit8000_defconfig | 1732 +-------------------- arch/arm/configs/dove_defconfig | 1482 ----------------- arch/arm/configs/ebsa110_defconfig | 692 +-------- arch/arm/configs/ecbat91_defconfig | 1226 +-------------- arch/arm/configs/edb7211_defconfig | 554 +------- arch/arm/configs/em_x270_defconfig | 1554 +------------------ arch/arm/configs/ep93xx_defconfig | 1340 ---------------- arch/arm/configs/eseries_pxa_defconfig | 1128 ------------- arch/arm/configs/ezx_defconfig | 1582 +------------------- arch/arm/configs/footbridge_defconfig | 1185 +-------------- arch/arm/configs/fortunet_defconfig | 538 +------- arch/arm/configs/g3evm_defconfig | 717 --------- arch/arm/configs/g4evm_defconfig | 722 --------- arch/arm/configs/h3600_defconfig | 1084 ------------- arch/arm/configs/h5000_defconfig | 917 +----------- arch/arm/configs/h7201_defconfig | 542 +------- arch/arm/configs/h7202_defconfig | 697 +-------- arch/arm/configs/hackkit_defconfig | 735 +--------- arch/arm/configs/htcherald_defconfig | 1073 +------------- arch/arm/configs/igep0020_defconfig | 1467 ----------------- arch/arm/configs/imote2_defconfig | 1649 +------------------- arch/arm/configs/integrator_defconfig | 817 +---------- arch/arm/configs/iop13xx_defconfig | 1061 +------------ arch/arm/configs/iop32x_defconfig | 1282 +--------------- arch/arm/configs/iop33x_defconfig | 1300 --------------- arch/arm/configs/ixp2000_defconfig | 1024 +------------ arch/arm/configs/ixp23xx_defconfig | 1315 +--------------- arch/arm/configs/ixp4xx_defconfig | 1394 +---------------- arch/arm/configs/jornada720_defconfig | 1062 ------------- arch/arm/configs/kafa_defconfig | 830 +---------- arch/arm/configs/kb9202_defconfig | 1179 +-------------- arch/arm/configs/kirkwood_defconfig | 1700 -------------------- arch/arm/configs/ks8695_defconfig | 946 ----------- arch/arm/configs/lart_defconfig | 824 +---------- arch/arm/configs/loki_defconfig | 1028 +------------ arch/arm/configs/lpd270_defconfig | 968 +------------ arch/arm/configs/lpd7a400_defconfig | 835 +---------- arch/arm/configs/lpd7a404_defconfig | 1050 +------------ arch/arm/configs/lubbock_defconfig | 762 +--------- arch/arm/configs/lusl7200_defconfig | 436 +----- arch/arm/configs/magician_defconfig | 1358 +---------------- arch/arm/configs/mainstone_defconfig | 755 +--------- arch/arm/configs/mini2440_defconfig | 1722 +-------------------- arch/arm/configs/mmp2_defconfig | 1135 ------------- arch/arm/configs/msm_defconfig | 830 +---------- arch/arm/configs/mv78xx0_defconfig | 1547 ------------------ arch/arm/configs/mx1_defconfig | 1018 +------------ arch/arm/configs/mx21_defconfig | 1072 ------------- arch/arm/configs/mx27_defconfig | 1152 -------------- arch/arm/configs/mx31pdk_defconfig | 728 --------- arch/arm/configs/mx3_defconfig | 1089 ------------- arch/arm/configs/mx51_defconfig | 1130 ------------- arch/arm/configs/n770_defconfig | 1283 --------------- arch/arm/configs/n8x0_defconfig | 1134 +------------- arch/arm/configs/neocore926_defconfig | 1205 +-------------- arch/arm/configs/neponset_defconfig | 1081 +------------- arch/arm/configs/netwinder_defconfig | 978 +------------ arch/arm/configs/netx_defconfig | 845 +---------- arch/arm/configs/nhk8815_defconfig | 1185 +-------------- arch/arm/configs/ns9xxx_defconfig | 23 - arch/arm/configs/nuc910_defconfig | 844 ---------- arch/arm/configs/nuc950_defconfig | 896 ----------- arch/arm/configs/nuc960_defconfig | 855 ---------- arch/arm/configs/omap3_beagle_defconfig | 1258 +--------------- arch/arm/configs/omap3_defconfig | 1969 ----------------------- arch/arm/configs/omap3_evm_defconfig | 1429 +----------------- arch/arm/configs/omap3_pandora_defconfig | 1640 +------------------- arch/arm/configs/omap3_stalker_lks_defconfig | 1541 ------------------ arch/arm/configs/omap3_touchbook_defconfig | 1809 --------------------- arch/arm/configs/omap_2430sdp_defconfig | 1181 +-------------- arch/arm/configs/omap_3430sdp_defconfig | 1553 +------------------ arch/arm/configs/omap_3630sdp_defconfig | 1456 ----------------- arch/arm/configs/omap_4430sdp_defconfig | 1157 -------------- arch/arm/configs/omap_apollon_2420_defconfig | 873 +---------- arch/arm/configs/omap_generic_1510_defconfig | 1089 +------------- arch/arm/configs/omap_generic_1610_defconfig | 1092 +------------- arch/arm/configs/omap_generic_1710_defconfig | 1014 +------------ arch/arm/configs/omap_generic_2420_defconfig | 619 +-------- arch/arm/configs/omap_h2_1610_defconfig | 1234 +--------------- arch/arm/configs/omap_h4_2420_defconfig | 1018 +------------ arch/arm/configs/omap_innovator_1510_defconfig | 1152 +-------------- arch/arm/configs/omap_innovator_1610_defconfig | 780 --------- arch/arm/configs/omap_ldp_defconfig | 1124 ------------- arch/arm/configs/omap_osk_5912_defconfig | 1003 ------------ arch/arm/configs/omap_perseus2_730_defconfig | 862 ---------- arch/arm/configs/omap_zoom2_defconfig | 1408 +----------------- arch/arm/configs/omap_zoom3_defconfig | 1455 ----------------- arch/arm/configs/onearm_defconfig | 1067 +------------- arch/arm/configs/orion5x_defconfig | 1693 -------------------- arch/arm/configs/overo_defconfig | 1621 +------------------- arch/arm/configs/palmte_defconfig | 712 --------- arch/arm/configs/palmtt_defconfig | 801 +---------- arch/arm/configs/palmz71_defconfig | 839 +---------- arch/arm/configs/palmz72_defconfig | 865 ---------- arch/arm/configs/pcm027_defconfig | 993 ------------ arch/arm/configs/picotux200_defconfig | 1207 +-------------- arch/arm/configs/pleb_defconfig | 712 +-------- arch/arm/configs/pnx4008_defconfig | 1286 +--------------- arch/arm/configs/pxa168_defconfig | 903 ----------- arch/arm/configs/pxa255-idp_defconfig | 753 +--------- arch/arm/configs/pxa3xx_defconfig | 1207 +-------------- arch/arm/configs/pxa910_defconfig | 820 ---------- arch/arm/configs/qil-a9260_defconfig | 1146 +-------------- arch/arm/configs/raumfeld_defconfig | 1690 -------------------- arch/arm/configs/realview-smp_defconfig | 1005 ------------ arch/arm/configs/realview_defconfig | 1001 ------------ arch/arm/configs/rpc_defconfig | 882 +----------- arch/arm/configs/rx51_defconfig | 1648 +------------------- arch/arm/configs/s3c2410_defconfig | 2018 ------------------------ arch/arm/configs/s3c6400_defconfig | 1445 ----------------- arch/arm/configs/s5p6440_defconfig | 947 ----------- arch/arm/configs/s5p6442_defconfig | 842 ---------- arch/arm/configs/s5pc100_defconfig | 977 ------------ arch/arm/configs/s5pc110_defconfig | 858 ---------- arch/arm/configs/s5pv210_defconfig | 861 ---------- arch/arm/configs/sam9_l9260_defconfig | 962 +----------- arch/arm/configs/shannon_defconfig | 837 +---------- arch/arm/configs/shark_defconfig | 1167 -------------- arch/arm/configs/simpad_defconfig | 886 +---------- arch/arm/configs/spear300_defconfig | 722 --------- arch/arm/configs/spear310_defconfig | 723 --------- arch/arm/configs/spear320_defconfig | 723 --------- arch/arm/configs/spear600_defconfig | 711 --------- arch/arm/configs/spitz_defconfig | 1547 +------------------ arch/arm/configs/stamp9g20_defconfig | 1327 ---------------- arch/arm/configs/stmp378x_defconfig | 1014 +------------ arch/arm/configs/stmp37xx_defconfig | 895 +----------- arch/arm/configs/sx1_defconfig | 1015 +------------ arch/arm/configs/tct_hammer_defconfig | 817 +---------- arch/arm/configs/trizeps4_defconfig | 1502 +----------------- arch/arm/configs/u300_defconfig | 1118 ------------- arch/arm/configs/u8500_defconfig | 621 -------- arch/arm/configs/usb-a9260_defconfig | 1039 +------------ arch/arm/configs/usb-a9263_defconfig | 1031 +------------ arch/arm/configs/versatile_defconfig | 928 +----------- arch/arm/configs/viper_defconfig | 1502 ------------------ arch/arm/configs/xcep_defconfig | 1031 +------------ arch/arm/configs/yl9200_defconfig | 1084 +------------- arch/arm/configs/zeus_defconfig | 1842 --------------------- 177 files changed, 652 insertions(+), 194157 deletions(-) -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 18:50 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-12 18:50 UTC (permalink / raw) To: linux-arm-kernel Hello Linus, On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > > When you brought up the problem you seemed absolutely convinced > > that nothing except your solution was going to be acceptable. > > That's not true. What's true is that you didn't seem to _understand_ > my solution, so I tried to push the understanding of it. > > There are always other solutions. I seriously doubt that Uwe's is a > maintainable one. That said, even a one-time "reduce the size of that > stinking pile of sh*t" is probably better than nothing. > > I hope you at least do agree that the current situation is a steaming > pile of sh*t. And yes, I _will_ remove the crap, both from POWER and > ARM, unless I see some serious tries at fixing it. I'm willing to try my solution, some others on the linux-arm-kernel lists considered it worth trying, too. Feel free to pull my tree[1]. Russell refused to take defconfig changes for a while now, so I don't expect merge problems if you do. If it helps the powerpc people I can reduce their defconfigs, too. Best regards Uwe [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 Uwe Kleine-K?nig (1): ARM: reduce defconfigs arch/arm/configs/acs5k_defconfig | 1146 -------------- arch/arm/configs/acs5k_tiny_defconfig | 860 ---------- arch/arm/configs/afeb9260_defconfig | 1157 +-------------- arch/arm/configs/am200epdkit_defconfig | 1044 +------------ arch/arm/configs/am3517_evm_defconfig | 1250 --------------- arch/arm/configs/ams_delta_defconfig | 1224 +-------------- arch/arm/configs/ap4evb_defconfig | 722 --------- arch/arm/configs/assabet_defconfig | 862 +---------- arch/arm/configs/at572d940hfek_defconfig | 1318 +--------------- arch/arm/configs/at91cap9adk_defconfig | 1107 +------------- arch/arm/configs/at91rm9200dk_defconfig | 955 +----------- arch/arm/configs/at91rm9200ek_defconfig | 942 +----------- arch/arm/configs/at91sam9260ek_defconfig | 958 +----------- arch/arm/configs/at91sam9261ek_defconfig | 1087 +------------- arch/arm/configs/at91sam9263ek_defconfig | 1103 +------------- arch/arm/configs/at91sam9g20ek_defconfig | 1049 +------------ arch/arm/configs/at91sam9rlek_defconfig | 864 +---------- arch/arm/configs/ateb9200_defconfig | 1222 +-------------- arch/arm/configs/badge4_defconfig | 1178 +-------------- arch/arm/configs/bcmring_defconfig | 721 --------- arch/arm/configs/cam60_defconfig | 1089 +------------- arch/arm/configs/carmeva_defconfig | 696 +-------- arch/arm/configs/cerfcube_defconfig | 851 +---------- arch/arm/configs/cm_t35_defconfig | 1577 +------------------ arch/arm/configs/cm_x2xx_defconfig | 1774 +--------------------- arch/arm/configs/cm_x300_defconfig | 1565 ------------------ arch/arm/configs/cns3420vb_defconfig | 759 --------- arch/arm/configs/colibri_pxa270_defconfig | 1556 ------------------ arch/arm/configs/colibri_pxa300_defconfig | 1082 ------------- arch/arm/configs/collie_defconfig | 887 +---------- arch/arm/configs/corgi_defconfig | 1621 +------------------- arch/arm/configs/cpu9260_defconfig | 1225 +-------------- arch/arm/configs/cpu9g20_defconfig | 1215 +-------------- arch/arm/configs/cpuat91_defconfig | 1207 +-------------- arch/arm/configs/csb337_defconfig | 1113 +------------- arch/arm/configs/csb637_defconfig | 1124 +------------- arch/arm/configs/da8xx_omapl_defconfig | 1205 -------------- arch/arm/configs/davinci_all_defconfig | 1641 ------------------- arch/arm/configs/devkit8000_defconfig | 1732 +-------------------- arch/arm/configs/dove_defconfig | 1482 ----------------- arch/arm/configs/ebsa110_defconfig | 692 +-------- arch/arm/configs/ecbat91_defconfig | 1226 +-------------- arch/arm/configs/edb7211_defconfig | 554 +------- arch/arm/configs/em_x270_defconfig | 1554 +------------------ arch/arm/configs/ep93xx_defconfig | 1340 ---------------- arch/arm/configs/eseries_pxa_defconfig | 1128 ------------- arch/arm/configs/ezx_defconfig | 1582 +------------------- arch/arm/configs/footbridge_defconfig | 1185 +-------------- arch/arm/configs/fortunet_defconfig | 538 +------- arch/arm/configs/g3evm_defconfig | 717 --------- arch/arm/configs/g4evm_defconfig | 722 --------- arch/arm/configs/h3600_defconfig | 1084 ------------- arch/arm/configs/h5000_defconfig | 917 +----------- arch/arm/configs/h7201_defconfig | 542 +------- arch/arm/configs/h7202_defconfig | 697 +-------- arch/arm/configs/hackkit_defconfig | 735 +--------- arch/arm/configs/htcherald_defconfig | 1073 +------------- arch/arm/configs/igep0020_defconfig | 1467 ----------------- arch/arm/configs/imote2_defconfig | 1649 +------------------- arch/arm/configs/integrator_defconfig | 817 +---------- arch/arm/configs/iop13xx_defconfig | 1061 +------------ arch/arm/configs/iop32x_defconfig | 1282 +--------------- arch/arm/configs/iop33x_defconfig | 1300 --------------- arch/arm/configs/ixp2000_defconfig | 1024 +------------ arch/arm/configs/ixp23xx_defconfig | 1315 +--------------- arch/arm/configs/ixp4xx_defconfig | 1394 +---------------- arch/arm/configs/jornada720_defconfig | 1062 ------------- arch/arm/configs/kafa_defconfig | 830 +---------- arch/arm/configs/kb9202_defconfig | 1179 +-------------- arch/arm/configs/kirkwood_defconfig | 1700 -------------------- arch/arm/configs/ks8695_defconfig | 946 ----------- arch/arm/configs/lart_defconfig | 824 +---------- arch/arm/configs/loki_defconfig | 1028 +------------ arch/arm/configs/lpd270_defconfig | 968 +------------ arch/arm/configs/lpd7a400_defconfig | 835 +---------- arch/arm/configs/lpd7a404_defconfig | 1050 +------------ arch/arm/configs/lubbock_defconfig | 762 +--------- arch/arm/configs/lusl7200_defconfig | 436 +----- arch/arm/configs/magician_defconfig | 1358 +---------------- arch/arm/configs/mainstone_defconfig | 755 +--------- arch/arm/configs/mini2440_defconfig | 1722 +-------------------- arch/arm/configs/mmp2_defconfig | 1135 ------------- arch/arm/configs/msm_defconfig | 830 +---------- arch/arm/configs/mv78xx0_defconfig | 1547 ------------------ arch/arm/configs/mx1_defconfig | 1018 +------------ arch/arm/configs/mx21_defconfig | 1072 ------------- arch/arm/configs/mx27_defconfig | 1152 -------------- arch/arm/configs/mx31pdk_defconfig | 728 --------- arch/arm/configs/mx3_defconfig | 1089 ------------- arch/arm/configs/mx51_defconfig | 1130 ------------- arch/arm/configs/n770_defconfig | 1283 --------------- arch/arm/configs/n8x0_defconfig | 1134 +------------- arch/arm/configs/neocore926_defconfig | 1205 +-------------- arch/arm/configs/neponset_defconfig | 1081 +------------- arch/arm/configs/netwinder_defconfig | 978 +------------ arch/arm/configs/netx_defconfig | 845 +---------- arch/arm/configs/nhk8815_defconfig | 1185 +-------------- arch/arm/configs/ns9xxx_defconfig | 23 - arch/arm/configs/nuc910_defconfig | 844 ---------- arch/arm/configs/nuc950_defconfig | 896 ----------- arch/arm/configs/nuc960_defconfig | 855 ---------- arch/arm/configs/omap3_beagle_defconfig | 1258 +--------------- arch/arm/configs/omap3_defconfig | 1969 ----------------------- arch/arm/configs/omap3_evm_defconfig | 1429 +----------------- arch/arm/configs/omap3_pandora_defconfig | 1640 +------------------- arch/arm/configs/omap3_stalker_lks_defconfig | 1541 ------------------ arch/arm/configs/omap3_touchbook_defconfig | 1809 --------------------- arch/arm/configs/omap_2430sdp_defconfig | 1181 +-------------- arch/arm/configs/omap_3430sdp_defconfig | 1553 +------------------ arch/arm/configs/omap_3630sdp_defconfig | 1456 ----------------- arch/arm/configs/omap_4430sdp_defconfig | 1157 -------------- arch/arm/configs/omap_apollon_2420_defconfig | 873 +---------- arch/arm/configs/omap_generic_1510_defconfig | 1089 +------------- arch/arm/configs/omap_generic_1610_defconfig | 1092 +------------- arch/arm/configs/omap_generic_1710_defconfig | 1014 +------------ arch/arm/configs/omap_generic_2420_defconfig | 619 +-------- arch/arm/configs/omap_h2_1610_defconfig | 1234 +--------------- arch/arm/configs/omap_h4_2420_defconfig | 1018 +------------ arch/arm/configs/omap_innovator_1510_defconfig | 1152 +-------------- arch/arm/configs/omap_innovator_1610_defconfig | 780 --------- arch/arm/configs/omap_ldp_defconfig | 1124 ------------- arch/arm/configs/omap_osk_5912_defconfig | 1003 ------------ arch/arm/configs/omap_perseus2_730_defconfig | 862 ---------- arch/arm/configs/omap_zoom2_defconfig | 1408 +----------------- arch/arm/configs/omap_zoom3_defconfig | 1455 ----------------- arch/arm/configs/onearm_defconfig | 1067 +------------- arch/arm/configs/orion5x_defconfig | 1693 -------------------- arch/arm/configs/overo_defconfig | 1621 +------------------- arch/arm/configs/palmte_defconfig | 712 --------- arch/arm/configs/palmtt_defconfig | 801 +---------- arch/arm/configs/palmz71_defconfig | 839 +---------- arch/arm/configs/palmz72_defconfig | 865 ---------- arch/arm/configs/pcm027_defconfig | 993 ------------ arch/arm/configs/picotux200_defconfig | 1207 +-------------- arch/arm/configs/pleb_defconfig | 712 +-------- arch/arm/configs/pnx4008_defconfig | 1286 +--------------- arch/arm/configs/pxa168_defconfig | 903 ----------- arch/arm/configs/pxa255-idp_defconfig | 753 +--------- arch/arm/configs/pxa3xx_defconfig | 1207 +-------------- arch/arm/configs/pxa910_defconfig | 820 ---------- arch/arm/configs/qil-a9260_defconfig | 1146 +-------------- arch/arm/configs/raumfeld_defconfig | 1690 -------------------- arch/arm/configs/realview-smp_defconfig | 1005 ------------ arch/arm/configs/realview_defconfig | 1001 ------------ arch/arm/configs/rpc_defconfig | 882 +----------- arch/arm/configs/rx51_defconfig | 1648 +------------------- arch/arm/configs/s3c2410_defconfig | 2018 ------------------------ arch/arm/configs/s3c6400_defconfig | 1445 ----------------- arch/arm/configs/s5p6440_defconfig | 947 ----------- arch/arm/configs/s5p6442_defconfig | 842 ---------- arch/arm/configs/s5pc100_defconfig | 977 ------------ arch/arm/configs/s5pc110_defconfig | 858 ---------- arch/arm/configs/s5pv210_defconfig | 861 ---------- arch/arm/configs/sam9_l9260_defconfig | 962 +----------- arch/arm/configs/shannon_defconfig | 837 +---------- arch/arm/configs/shark_defconfig | 1167 -------------- arch/arm/configs/simpad_defconfig | 886 +---------- arch/arm/configs/spear300_defconfig | 722 --------- arch/arm/configs/spear310_defconfig | 723 --------- arch/arm/configs/spear320_defconfig | 723 --------- arch/arm/configs/spear600_defconfig | 711 --------- arch/arm/configs/spitz_defconfig | 1547 +------------------ arch/arm/configs/stamp9g20_defconfig | 1327 ---------------- arch/arm/configs/stmp378x_defconfig | 1014 +------------ arch/arm/configs/stmp37xx_defconfig | 895 +----------- arch/arm/configs/sx1_defconfig | 1015 +------------ arch/arm/configs/tct_hammer_defconfig | 817 +---------- arch/arm/configs/trizeps4_defconfig | 1502 +----------------- arch/arm/configs/u300_defconfig | 1118 ------------- arch/arm/configs/u8500_defconfig | 621 -------- arch/arm/configs/usb-a9260_defconfig | 1039 +------------ arch/arm/configs/usb-a9263_defconfig | 1031 +------------ arch/arm/configs/versatile_defconfig | 928 +----------- arch/arm/configs/viper_defconfig | 1502 ------------------ arch/arm/configs/xcep_defconfig | 1031 +------------ arch/arm/configs/yl9200_defconfig | 1084 +------------- arch/arm/configs/zeus_defconfig | 1842 --------------------- 177 files changed, 652 insertions(+), 194157 deletions(-) -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-12 18:50 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-12 18:50 UTC (permalink / raw) To: Linus Torvalds Cc: Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre Hello Linus, On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > > When you brought up the problem you seemed absolutely convinced > > that nothing except your solution was going to be acceptable. > > That's not true. What's true is that you didn't seem to _understand_ > my solution, so I tried to push the understanding of it. > > There are always other solutions. I seriously doubt that Uwe's is a > maintainable one. That said, even a one-time "reduce the size of that > stinking pile of sh*t" is probably better than nothing. > > I hope you at least do agree that the current situation is a steaming > pile of sh*t. And yes, I _will_ remove the crap, both from POWER and > ARM, unless I see some serious tries at fixing it. I'm willing to try my solution, some others on the linux-arm-kernel lists considered it worth trying, too. Feel free to pull my tree[1]. Russell refused to take defconfig changes for a while now, so I don't expect merge problems if you do. If it helps the powerpc people I can reduce their defconfigs, too. Best regards Uwe [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 Uwe Kleine-König (1): ARM: reduce defconfigs arch/arm/configs/acs5k_defconfig | 1146 -------------- arch/arm/configs/acs5k_tiny_defconfig | 860 ---------- arch/arm/configs/afeb9260_defconfig | 1157 +-------------- arch/arm/configs/am200epdkit_defconfig | 1044 +------------ arch/arm/configs/am3517_evm_defconfig | 1250 --------------- arch/arm/configs/ams_delta_defconfig | 1224 +-------------- arch/arm/configs/ap4evb_defconfig | 722 --------- arch/arm/configs/assabet_defconfig | 862 +---------- arch/arm/configs/at572d940hfek_defconfig | 1318 +--------------- arch/arm/configs/at91cap9adk_defconfig | 1107 +------------- arch/arm/configs/at91rm9200dk_defconfig | 955 +----------- arch/arm/configs/at91rm9200ek_defconfig | 942 +----------- arch/arm/configs/at91sam9260ek_defconfig | 958 +----------- arch/arm/configs/at91sam9261ek_defconfig | 1087 +------------- arch/arm/configs/at91sam9263ek_defconfig | 1103 +------------- arch/arm/configs/at91sam9g20ek_defconfig | 1049 +------------ arch/arm/configs/at91sam9rlek_defconfig | 864 +---------- arch/arm/configs/ateb9200_defconfig | 1222 +-------------- arch/arm/configs/badge4_defconfig | 1178 +-------------- arch/arm/configs/bcmring_defconfig | 721 --------- arch/arm/configs/cam60_defconfig | 1089 +------------- arch/arm/configs/carmeva_defconfig | 696 +-------- arch/arm/configs/cerfcube_defconfig | 851 +---------- arch/arm/configs/cm_t35_defconfig | 1577 +------------------ arch/arm/configs/cm_x2xx_defconfig | 1774 +--------------------- arch/arm/configs/cm_x300_defconfig | 1565 ------------------ arch/arm/configs/cns3420vb_defconfig | 759 --------- arch/arm/configs/colibri_pxa270_defconfig | 1556 ------------------ arch/arm/configs/colibri_pxa300_defconfig | 1082 ------------- arch/arm/configs/collie_defconfig | 887 +---------- arch/arm/configs/corgi_defconfig | 1621 +------------------- arch/arm/configs/cpu9260_defconfig | 1225 +-------------- arch/arm/configs/cpu9g20_defconfig | 1215 +-------------- arch/arm/configs/cpuat91_defconfig | 1207 +-------------- arch/arm/configs/csb337_defconfig | 1113 +------------- arch/arm/configs/csb637_defconfig | 1124 +------------- arch/arm/configs/da8xx_omapl_defconfig | 1205 -------------- arch/arm/configs/davinci_all_defconfig | 1641 ------------------- arch/arm/configs/devkit8000_defconfig | 1732 +-------------------- arch/arm/configs/dove_defconfig | 1482 ----------------- arch/arm/configs/ebsa110_defconfig | 692 +-------- arch/arm/configs/ecbat91_defconfig | 1226 +-------------- arch/arm/configs/edb7211_defconfig | 554 +------- arch/arm/configs/em_x270_defconfig | 1554 +------------------ arch/arm/configs/ep93xx_defconfig | 1340 ---------------- arch/arm/configs/eseries_pxa_defconfig | 1128 ------------- arch/arm/configs/ezx_defconfig | 1582 +------------------- arch/arm/configs/footbridge_defconfig | 1185 +-------------- arch/arm/configs/fortunet_defconfig | 538 +------- arch/arm/configs/g3evm_defconfig | 717 --------- arch/arm/configs/g4evm_defconfig | 722 --------- arch/arm/configs/h3600_defconfig | 1084 ------------- arch/arm/configs/h5000_defconfig | 917 +----------- arch/arm/configs/h7201_defconfig | 542 +------- arch/arm/configs/h7202_defconfig | 697 +-------- arch/arm/configs/hackkit_defconfig | 735 +--------- arch/arm/configs/htcherald_defconfig | 1073 +------------- arch/arm/configs/igep0020_defconfig | 1467 ----------------- arch/arm/configs/imote2_defconfig | 1649 +------------------- arch/arm/configs/integrator_defconfig | 817 +---------- arch/arm/configs/iop13xx_defconfig | 1061 +------------ arch/arm/configs/iop32x_defconfig | 1282 +--------------- arch/arm/configs/iop33x_defconfig | 1300 --------------- arch/arm/configs/ixp2000_defconfig | 1024 +------------ arch/arm/configs/ixp23xx_defconfig | 1315 +--------------- arch/arm/configs/ixp4xx_defconfig | 1394 +---------------- arch/arm/configs/jornada720_defconfig | 1062 ------------- arch/arm/configs/kafa_defconfig | 830 +---------- arch/arm/configs/kb9202_defconfig | 1179 +-------------- arch/arm/configs/kirkwood_defconfig | 1700 -------------------- arch/arm/configs/ks8695_defconfig | 946 ----------- arch/arm/configs/lart_defconfig | 824 +---------- arch/arm/configs/loki_defconfig | 1028 +------------ arch/arm/configs/lpd270_defconfig | 968 +------------ arch/arm/configs/lpd7a400_defconfig | 835 +---------- arch/arm/configs/lpd7a404_defconfig | 1050 +------------ arch/arm/configs/lubbock_defconfig | 762 +--------- arch/arm/configs/lusl7200_defconfig | 436 +----- arch/arm/configs/magician_defconfig | 1358 +---------------- arch/arm/configs/mainstone_defconfig | 755 +--------- arch/arm/configs/mini2440_defconfig | 1722 +-------------------- arch/arm/configs/mmp2_defconfig | 1135 ------------- arch/arm/configs/msm_defconfig | 830 +---------- arch/arm/configs/mv78xx0_defconfig | 1547 ------------------ arch/arm/configs/mx1_defconfig | 1018 +------------ arch/arm/configs/mx21_defconfig | 1072 ------------- arch/arm/configs/mx27_defconfig | 1152 -------------- arch/arm/configs/mx31pdk_defconfig | 728 --------- arch/arm/configs/mx3_defconfig | 1089 ------------- arch/arm/configs/mx51_defconfig | 1130 ------------- arch/arm/configs/n770_defconfig | 1283 --------------- arch/arm/configs/n8x0_defconfig | 1134 +------------- arch/arm/configs/neocore926_defconfig | 1205 +-------------- arch/arm/configs/neponset_defconfig | 1081 +------------- arch/arm/configs/netwinder_defconfig | 978 +------------ arch/arm/configs/netx_defconfig | 845 +---------- arch/arm/configs/nhk8815_defconfig | 1185 +-------------- arch/arm/configs/ns9xxx_defconfig | 23 - arch/arm/configs/nuc910_defconfig | 844 ---------- arch/arm/configs/nuc950_defconfig | 896 ----------- arch/arm/configs/nuc960_defconfig | 855 ---------- arch/arm/configs/omap3_beagle_defconfig | 1258 +--------------- arch/arm/configs/omap3_defconfig | 1969 ----------------------- arch/arm/configs/omap3_evm_defconfig | 1429 +----------------- arch/arm/configs/omap3_pandora_defconfig | 1640 +------------------- arch/arm/configs/omap3_stalker_lks_defconfig | 1541 ------------------ arch/arm/configs/omap3_touchbook_defconfig | 1809 --------------------- arch/arm/configs/omap_2430sdp_defconfig | 1181 +-------------- arch/arm/configs/omap_3430sdp_defconfig | 1553 +------------------ arch/arm/configs/omap_3630sdp_defconfig | 1456 ----------------- arch/arm/configs/omap_4430sdp_defconfig | 1157 -------------- arch/arm/configs/omap_apollon_2420_defconfig | 873 +---------- arch/arm/configs/omap_generic_1510_defconfig | 1089 +------------- arch/arm/configs/omap_generic_1610_defconfig | 1092 +------------- arch/arm/configs/omap_generic_1710_defconfig | 1014 +------------ arch/arm/configs/omap_generic_2420_defconfig | 619 +-------- arch/arm/configs/omap_h2_1610_defconfig | 1234 +--------------- arch/arm/configs/omap_h4_2420_defconfig | 1018 +------------ arch/arm/configs/omap_innovator_1510_defconfig | 1152 +-------------- arch/arm/configs/omap_innovator_1610_defconfig | 780 --------- arch/arm/configs/omap_ldp_defconfig | 1124 ------------- arch/arm/configs/omap_osk_5912_defconfig | 1003 ------------ arch/arm/configs/omap_perseus2_730_defconfig | 862 ---------- arch/arm/configs/omap_zoom2_defconfig | 1408 +----------------- arch/arm/configs/omap_zoom3_defconfig | 1455 ----------------- arch/arm/configs/onearm_defconfig | 1067 +------------- arch/arm/configs/orion5x_defconfig | 1693 -------------------- arch/arm/configs/overo_defconfig | 1621 +------------------- arch/arm/configs/palmte_defconfig | 712 --------- arch/arm/configs/palmtt_defconfig | 801 +---------- arch/arm/configs/palmz71_defconfig | 839 +---------- arch/arm/configs/palmz72_defconfig | 865 ---------- arch/arm/configs/pcm027_defconfig | 993 ------------ arch/arm/configs/picotux200_defconfig | 1207 +-------------- arch/arm/configs/pleb_defconfig | 712 +-------- arch/arm/configs/pnx4008_defconfig | 1286 +--------------- arch/arm/configs/pxa168_defconfig | 903 ----------- arch/arm/configs/pxa255-idp_defconfig | 753 +--------- arch/arm/configs/pxa3xx_defconfig | 1207 +-------------- arch/arm/configs/pxa910_defconfig | 820 ---------- arch/arm/configs/qil-a9260_defconfig | 1146 +-------------- arch/arm/configs/raumfeld_defconfig | 1690 -------------------- arch/arm/configs/realview-smp_defconfig | 1005 ------------ arch/arm/configs/realview_defconfig | 1001 ------------ arch/arm/configs/rpc_defconfig | 882 +----------- arch/arm/configs/rx51_defconfig | 1648 +------------------- arch/arm/configs/s3c2410_defconfig | 2018 ------------------------ arch/arm/configs/s3c6400_defconfig | 1445 ----------------- arch/arm/configs/s5p6440_defconfig | 947 ----------- arch/arm/configs/s5p6442_defconfig | 842 ---------- arch/arm/configs/s5pc100_defconfig | 977 ------------ arch/arm/configs/s5pc110_defconfig | 858 ---------- arch/arm/configs/s5pv210_defconfig | 861 ---------- arch/arm/configs/sam9_l9260_defconfig | 962 +----------- arch/arm/configs/shannon_defconfig | 837 +---------- arch/arm/configs/shark_defconfig | 1167 -------------- arch/arm/configs/simpad_defconfig | 886 +---------- arch/arm/configs/spear300_defconfig | 722 --------- arch/arm/configs/spear310_defconfig | 723 --------- arch/arm/configs/spear320_defconfig | 723 --------- arch/arm/configs/spear600_defconfig | 711 --------- arch/arm/configs/spitz_defconfig | 1547 +------------------ arch/arm/configs/stamp9g20_defconfig | 1327 ---------------- arch/arm/configs/stmp378x_defconfig | 1014 +------------ arch/arm/configs/stmp37xx_defconfig | 895 +----------- arch/arm/configs/sx1_defconfig | 1015 +------------ arch/arm/configs/tct_hammer_defconfig | 817 +---------- arch/arm/configs/trizeps4_defconfig | 1502 +----------------- arch/arm/configs/u300_defconfig | 1118 ------------- arch/arm/configs/u8500_defconfig | 621 -------- arch/arm/configs/usb-a9260_defconfig | 1039 +------------ arch/arm/configs/usb-a9263_defconfig | 1031 +------------ arch/arm/configs/versatile_defconfig | 928 +----------- arch/arm/configs/viper_defconfig | 1502 ------------------ arch/arm/configs/xcep_defconfig | 1031 +------------ arch/arm/configs/yl9200_defconfig | 1084 +------------- arch/arm/configs/zeus_defconfig | 1842 --------------------- 177 files changed, 652 insertions(+), 194157 deletions(-) -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 18:50 ` Uwe Kleine-König @ 2010-07-12 19:04 ` Linus Torvalds -1 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 19:04 UTC (permalink / raw) To: Uwe Kleine-König Cc: Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre 2010/7/12 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: > > I'm willing to try my solution, some others on the linux-arm-kernel > lists considered it worth trying, too. Feel free to pull my tree[1]. > Russell refused to take defconfig changes for a while now, so I don't > expect merge problems if you do. Well, I can hardly refuse a pull that removes almost 200k lines. So I'd happily pull it. Just this single line in your email is a very very powerful thing: > 177 files changed, 652 insertions(+), 194157 deletions(-) However, before I would pull, I'd definitely like to make sure we at least have some way forward too, and clarify some issues. So I have a couple of questions: - is this guaranteed to be a no-op as things stand now, and what are the secondary effects of it? Put another way: I realize that fairly late in the -rc series is actually a really good time to do this, rather than during the merge window itself when things are in flux. However, while it would be a good time to pull this for that reason, it's also a _horrible_ time to pull if it then regresses the defconfig uses, or if it causes horrible problems for linux-next merging etc. - what happens when somebody wants to update the defconfig files? This is a question that involves a number of people, because over the last half year, we've had lots of people changing them. "git shortlog -ns" on that ARM config directory gives 39 people in the last half year, with the top looking roughly like 26 Ben Dooks 10 Tony Lindgren 4 Haojian Zhuang 4 Kukjin Kim 3 Santosh Shilimkar 3 Sriram 2 Janusz Krzysztofik .... and how are these people going to do their updates going forward without re-introducing the noise? IOW, I'd _love_ to get rid of almost 200k lines of noise and your approach would seem to have the advantage that it's "invisible" to users. But I would want to get some kind of assurance that it's practical to do so. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 19:04 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 19:04 UTC (permalink / raw) To: linux-arm-kernel 2010/7/12 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>: > > I'm willing to try my solution, some others on the linux-arm-kernel > lists considered it worth trying, too. ?Feel free to pull my tree[1]. > Russell refused to take defconfig changes for a while now, so I don't > expect merge problems if you do. Well, I can hardly refuse a pull that removes almost 200k lines. So I'd happily pull it. Just this single line in your email is a very very powerful thing: > 177 files changed, 652 insertions(+), 194157 deletions(-) However, before I would pull, I'd definitely like to make sure we at least have some way forward too, and clarify some issues. So I have a couple of questions: - is this guaranteed to be a no-op as things stand now, and what are the secondary effects of it? Put another way: I realize that fairly late in the -rc series is actually a really good time to do this, rather than during the merge window itself when things are in flux. However, while it would be a good time to pull this for that reason, it's also a _horrible_ time to pull if it then regresses the defconfig uses, or if it causes horrible problems for linux-next merging etc. - what happens when somebody wants to update the defconfig files? This is a question that involves a number of people, because over the last half year, we've had lots of people changing them. "git shortlog -ns" on that ARM config directory gives 39 people in the last half year, with the top looking roughly like 26 Ben Dooks 10 Tony Lindgren 4 Haojian Zhuang 4 Kukjin Kim 3 Santosh Shilimkar 3 Sriram 2 Janusz Krzysztofik .... and how are these people going to do their updates going forward without re-introducing the noise? IOW, I'd _love_ to get rid of almost 200k lines of noise and your approach would seem to have the advantage that it's "invisible" to users. But I would want to get some kind of assurance that it's practical to do so. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 19:04 ` Linus Torvalds @ 2010-07-12 19:17 ` Nicolas Pitre -1 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 19:17 UTC (permalink / raw) To: Linus Torvalds Cc: Uwe Kleine-König, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap On Mon, 12 Jul 2010, Linus Torvalds wrote: > I'd happily pull it. Just this single line in your email is a very > very powerful thing: > > > 177 files changed, 652 insertions(+), 194157 deletions(-) > > However, before I would pull, I'd definitely like to make sure we at > least have some way forward too, and clarify some issues. So I have a > couple of questions: > > - is this guaranteed to be a no-op as things stand now, and what are > the secondary effects of it? > > Put another way: I realize that fairly late in the -rc series is > actually a really good time to do this, rather than during the merge > window itself when things are in flux. However, while it would be a > good time to pull this for that reason, it's also a _horrible_ time to > pull if it then regresses the defconfig uses, or if it causes horrible > problems for linux-next merging etc. This cannot be any worse than wholesale removal of those files as you were contemplating at some point. Furthermore, on ARM we have someone providing automatic rebuild of all defconfigs already, so any serious issue should be noticed right away. > - what happens when somebody wants to update the defconfig files? > > This is a question that involves a number of people, because over > the last half year, we've had lots of people changing them. "git > shortlog -ns" on that ARM config directory gives 39 people in the last > half year, with the top looking roughly like > > 26 Ben Dooks > 10 Tony Lindgren > 4 Haojian Zhuang > 4 Kukjin Kim > 3 Santosh Shilimkar > 3 Sriram > 2 Janusz Krzysztofik > .... > > and how are these people going to do their updates going forward > without re-introducing the noise? > > IOW, I'd _love_ to get rid of almost 200k lines of noise and your > approach would seem to have the advantage that it's "invisible" to > users. But I would want to get some kind of assurance that it's > practical to do so. I think Uwe could provide his script and add it to the kernel tree. Then all architectures could benefit from it. Having the defconfig files contain only those options which are different from the defaults is certainly more readable, even on x86. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 19:17 ` Nicolas Pitre 0 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 19:17 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, Linus Torvalds wrote: > I'd happily pull it. Just this single line in your email is a very > very powerful thing: > > > 177 files changed, 652 insertions(+), 194157 deletions(-) > > However, before I would pull, I'd definitely like to make sure we at > least have some way forward too, and clarify some issues. So I have a > couple of questions: > > - is this guaranteed to be a no-op as things stand now, and what are > the secondary effects of it? > > Put another way: I realize that fairly late in the -rc series is > actually a really good time to do this, rather than during the merge > window itself when things are in flux. However, while it would be a > good time to pull this for that reason, it's also a _horrible_ time to > pull if it then regresses the defconfig uses, or if it causes horrible > problems for linux-next merging etc. This cannot be any worse than wholesale removal of those files as you were contemplating at some point. Furthermore, on ARM we have someone providing automatic rebuild of all defconfigs already, so any serious issue should be noticed right away. > - what happens when somebody wants to update the defconfig files? > > This is a question that involves a number of people, because over > the last half year, we've had lots of people changing them. "git > shortlog -ns" on that ARM config directory gives 39 people in the last > half year, with the top looking roughly like > > 26 Ben Dooks > 10 Tony Lindgren > 4 Haojian Zhuang > 4 Kukjin Kim > 3 Santosh Shilimkar > 3 Sriram > 2 Janusz Krzysztofik > .... > > and how are these people going to do their updates going forward > without re-introducing the noise? > > IOW, I'd _love_ to get rid of almost 200k lines of noise and your > approach would seem to have the advantage that it's "invisible" to > users. But I would want to get some kind of assurance that it's > practical to do so. I think Uwe could provide his script and add it to the kernel tree. Then all architectures could benefit from it. Having the defconfig files contain only those options which are different from the defaults is certainly more readable, even on x86. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 19:17 ` Nicolas Pitre (?) @ 2010-07-12 19:34 ` Linus Torvalds -1 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 19:34 UTC (permalink / raw) To: Nicolas Pitre Cc: Uwe Kleine-König, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> >> Put another way: I realize that fairly late in the -rc series is >> actually a really good time to do this, rather than during the merge >> window itself when things are in flux. However, while it would be a >> good time to pull this for that reason, it's also a _horrible_ time to >> pull if it then regresses the defconfig uses, or if it causes horrible >> problems for linux-next merging etc. > > This cannot be any worse than wholesale removal of those files as you > were contemplating at some point. Furthermore, on ARM we have someone > providing automatic rebuild of all defconfigs already, so any serious > issue should be noticed right away. You aren't really answering the question. The thing is, the wholesale removal wouldn't happen during the late -rc anyway, and it wouldn't cause any merge issues (merge conflicts where the file is just to be removed are trivial to take care of). So I'm really asking about the issue of "how does this work during the late -rc phase". Where the _timing_ is the important thing. Because I could as easily pull after 2.6.35 is out. That has it's own downsides (with all the merging going on), but at the same time, it's clearly the right time for a large change. So when I ask about timing and "how does this work in late -rc", it's really about how safe it is to do now. Because if it isn't very obviously safe, I can't pull it. One part of the "obviously safe" thing is verification for each defconfig file that the end result is identical with the reduced version. Uwe implied that it was, and that was clearly the intention, but was there some explicit verification that yes, the before-and-after configurations are 100% the same? Also, I assume that while it's _mostly_ a transparent change to users, it does require that people do "make oldconfig" with the reduced defconfig file first, in order to avoid having to answer with the defaults. No? And the reduced defconfig files obviously do depend on the default in the Kconfig files themselves, so it does have that kind of fairly subtle semantic change that may not be entirely obvious or easy to notice. So from a timing standpoint, I just want to be convinced that "late -rc" really is the right thing. I'm not entirely sure it is, even though I do see advantages. > I think Uwe could provide his script and add it to the kernel tree. > Then all architectures could benefit from it. Having the defconfig > files contain only those options which are different from the defaults > is certainly more readable, even on x86. Quite possible. But maintainers would need to be on the lookout of people actually using the script, and refusing to apply patches that re-introduce the whole big thing. I also haven't actually seen the script - I don't think Uwe ever posted it - so maybe it's some very fragile thing. Hard to judge on no real information ;^p Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 19:34 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 19:34 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> >> ? ?Put another way: I realize that fairly late in the -rc series is >> actually a really good time to do this, rather than during the merge >> window itself when things are in flux. However, while it would be a >> good time to pull this for that reason, it's also a _horrible_ time to >> pull if it then regresses the defconfig uses, or if it causes horrible >> problems for linux-next merging etc. > > This cannot be any worse than wholesale removal of those files as you > were contemplating at some point. ?Furthermore, on ARM we have someone > providing automatic rebuild of all defconfigs already, so any serious > issue should be noticed right away. You aren't really answering the question. The thing is, the wholesale removal wouldn't happen during the late -rc anyway, and it wouldn't cause any merge issues (merge conflicts where the file is just to be removed are trivial to take care of). So I'm really asking about the issue of "how does this work during the late -rc phase". Where the _timing_ is the important thing. Because I could as easily pull after 2.6.35 is out. That has it's own downsides (with all the merging going on), but at the same time, it's clearly the right time for a large change. So when I ask about timing and "how does this work in late -rc", it's really about how safe it is to do now. Because if it isn't very obviously safe, I can't pull it. One part of the "obviously safe" thing is verification for each defconfig file that the end result is identical with the reduced version. Uwe implied that it was, and that was clearly the intention, but was there some explicit verification that yes, the before-and-after configurations are 100% the same? Also, I assume that while it's _mostly_ a transparent change to users, it does require that people do "make oldconfig" with the reduced defconfig file first, in order to avoid having to answer with the defaults. No? And the reduced defconfig files obviously do depend on the default in the Kconfig files themselves, so it does have that kind of fairly subtle semantic change that may not be entirely obvious or easy to notice. So from a timing standpoint, I just want to be convinced that "late -rc" really is the right thing. I'm not entirely sure it is, even though I do see advantages. > I think Uwe could provide his script and add it to the kernel tree. > Then all architectures could benefit from it. ?Having the defconfig > files contain only those options which are different from the defaults > is certainly more readable, even on x86. Quite possible. But maintainers would need to be on the lookout of people actually using the script, and refusing to apply patches that re-introduce the whole big thing. I also haven't actually seen the script - I don't think Uwe ever posted it - so maybe it's some very fragile thing. Hard to judge on no real information ;^p Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-12 19:34 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 19:34 UTC (permalink / raw) To: Nicolas Pitre Cc: Daniel Walker, Russell King - ARM Linux, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, Grant Likely, linux-omap, Uwe Kleine-König, Eric Miao, linux-arm-kernel On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> >> Put another way: I realize that fairly late in the -rc series is >> actually a really good time to do this, rather than during the merge >> window itself when things are in flux. However, while it would be a >> good time to pull this for that reason, it's also a _horrible_ time to >> pull if it then regresses the defconfig uses, or if it causes horrible >> problems for linux-next merging etc. > > This cannot be any worse than wholesale removal of those files as you > were contemplating at some point. Furthermore, on ARM we have someone > providing automatic rebuild of all defconfigs already, so any serious > issue should be noticed right away. You aren't really answering the question. The thing is, the wholesale removal wouldn't happen during the late -rc anyway, and it wouldn't cause any merge issues (merge conflicts where the file is just to be removed are trivial to take care of). So I'm really asking about the issue of "how does this work during the late -rc phase". Where the _timing_ is the important thing. Because I could as easily pull after 2.6.35 is out. That has it's own downsides (with all the merging going on), but at the same time, it's clearly the right time for a large change. So when I ask about timing and "how does this work in late -rc", it's really about how safe it is to do now. Because if it isn't very obviously safe, I can't pull it. One part of the "obviously safe" thing is verification for each defconfig file that the end result is identical with the reduced version. Uwe implied that it was, and that was clearly the intention, but was there some explicit verification that yes, the before-and-after configurations are 100% the same? Also, I assume that while it's _mostly_ a transparent change to users, it does require that people do "make oldconfig" with the reduced defconfig file first, in order to avoid having to answer with the defaults. No? And the reduced defconfig files obviously do depend on the default in the Kconfig files themselves, so it does have that kind of fairly subtle semantic change that may not be entirely obvious or easy to notice. So from a timing standpoint, I just want to be convinced that "late -rc" really is the right thing. I'm not entirely sure it is, even though I do see advantages. > I think Uwe could provide his script and add it to the kernel tree. > Then all architectures could benefit from it. Having the defconfig > files contain only those options which are different from the defaults > is certainly more readable, even on x86. Quite possible. But maintainers would need to be on the lookout of people actually using the script, and refusing to apply patches that re-introduce the whole big thing. I also haven't actually seen the script - I don't think Uwe ever posted it - so maybe it's some very fragile thing. Hard to judge on no real information ;^p Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 19:34 ` Linus Torvalds @ 2010-07-12 19:50 ` Grant Likely -1 siblings, 0 replies; 133+ messages in thread From: Grant Likely @ 2010-07-12 19:50 UTC (permalink / raw) To: Linus Torvalds Cc: Nicolas Pitre, Daniel Walker, Russell King - ARM Linux, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, linux-omap, Uwe Kleine-König, Eric Miao, linux-arm-kernel On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> I think Uwe could provide his script and add it to the kernel tree. >> Then all architectures could benefit from it. Having the defconfig >> files contain only those options which are different from the defaults >> is certainly more readable, even on x86. > > Quite possible. But maintainers would need to be on the lookout of > people actually using the script, and refusing to apply patches that > re-introduce the whole big thing. I can (partially) speak for powerpc. If ARM uses this approach, then I think we can do the same. After the defconfigs are trimmed, I certainly won't pick up any more full defconfigs. Of course, I'm also operating under the assumption that this is a temporary measure until one of the better solutions is implemented. I do suspect that the trimmed defconfigs will tend to be unstable and will still require manual maintenance. I think the Kconfig fragments approach is the most promising if the dependencies issue can be solved. g. ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 19:50 ` Grant Likely 0 siblings, 0 replies; 133+ messages in thread From: Grant Likely @ 2010-07-12 19:50 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> I think Uwe could provide his script and add it to the kernel tree. >> Then all architectures could benefit from it. ?Having the defconfig >> files contain only those options which are different from the defaults >> is certainly more readable, even on x86. > > Quite possible. But maintainers would need to be on the lookout of > people actually using the script, and refusing to apply patches that > re-introduce the whole big thing. I can (partially) speak for powerpc. If ARM uses this approach, then I think we can do the same. After the defconfigs are trimmed, I certainly won't pick up any more full defconfigs. Of course, I'm also operating under the assumption that this is a temporary measure until one of the better solutions is implemented. I do suspect that the trimmed defconfigs will tend to be unstable and will still require manual maintenance. I think the Kconfig fragments approach is the most promising if the dependencies issue can be solved. g. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 19:50 ` Grant Likely @ 2010-07-13 7:07 ` Uwe Kleine-König -1 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-13 7:07 UTC (permalink / raw) To: Grant Likely Cc: Linus Torvalds, Nicolas Pitre, Daniel Walker, Russell King - ARM Linux, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, linux-omap, Eric Miao, linux-arm-kernel Hi On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > >> I think Uwe could provide his script and add it to the kernel tree. > >> Then all architectures could benefit from it. Having the defconfig > >> files contain only those options which are different from the defaults > >> is certainly more readable, even on x86. > > > > Quite possible. But maintainers would need to be on the lookout of > > people actually using the script, and refusing to apply patches that > > re-introduce the whole big thing. > > I can (partially) speak for powerpc. If ARM uses this approach, then > I think we can do the same. After the defconfigs are trimmed, I > certainly won't pick up any more full defconfigs. I just restarted my script on the powerpc defconfigs basing on rc5, I assume they complete in a few days time. > Of course, I'm also operating under the assumption that this is a > temporary measure until one of the better solutions is implemented. ack > I > do suspect that the trimmed defconfigs will tend to be unstable and > will still require manual maintenance. I think the Kconfig fragments > approach is the most promising if the dependencies issue can be > solved. I don't understand what you mean with unstable here. They are sensible to changed defaults in the Kconfig files which you can consider to be good or bad. And ack, I like the Kconfig approach, too. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-13 7:07 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-13 7:07 UTC (permalink / raw) To: linux-arm-kernel Hi On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > >> I think Uwe could provide his script and add it to the kernel tree. > >> Then all architectures could benefit from it. ?Having the defconfig > >> files contain only those options which are different from the defaults > >> is certainly more readable, even on x86. > > > > Quite possible. But maintainers would need to be on the lookout of > > people actually using the script, and refusing to apply patches that > > re-introduce the whole big thing. > > I can (partially) speak for powerpc. If ARM uses this approach, then > I think we can do the same. After the defconfigs are trimmed, I > certainly won't pick up any more full defconfigs. I just restarted my script on the powerpc defconfigs basing on rc5, I assume they complete in a few days time. > Of course, I'm also operating under the assumption that this is a > temporary measure until one of the better solutions is implemented. ack > I > do suspect that the trimmed defconfigs will tend to be unstable and > will still require manual maintenance. I think the Kconfig fragments > approach is the most promising if the dependencies issue can be > solved. I don't understand what you mean with unstable here. They are sensible to changed defaults in the Kconfig files which you can consider to be good or bad. And ack, I like the Kconfig approach, too. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* optimized script [Was: ARM defconfig files] 2010-07-13 7:07 ` Uwe Kleine-König (?) @ 2010-07-13 8:07 ` Uwe Kleine-König -1 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-13 8:07 UTC (permalink / raw) To: Linus Torvalds Cc: Grant Likely, Nicolas Pitre, Daniel Walker, Russell King - ARM Linux, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, linux-omap, Eric Miao, linux-arm-kernel, Stephen Rothwell, Olof Johansson, Benjamin Herrenschmidt, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 1548 bytes --] Hello, On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote: > Hi > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > <torvalds@linux-foundation.org> wrote: > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > >> I think Uwe could provide his script and add it to the kernel tree. > > >> Then all architectures could benefit from it. Having the defconfig > > >> files contain only those options which are different from the defaults > > >> is certainly more readable, even on x86. > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > people actually using the script, and refusing to apply patches that > > > re-introduce the whole big thing. > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > I think we can do the same. After the defconfigs are trimmed, I > > certainly won't pick up any more full defconfigs. > I just restarted my script on the powerpc defconfigs basing on rc5, I > assume they complete in a few days time. So Stephen was faster than me. I don't know yet how he optimised my script, meanwhile I put some efforts into it, too by just checking lines that match "^(# )?CONFIG_". Find it attached. I will start to reduce the remaining configs (i.e. all but arm and powerpc). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | [-- Attachment #2: reduce_defconfig --] [-- Type: text/plain, Size: 1899 bytes --] #! /usr/bin/env python # vim: set fileencoding=utf-8 : # Copyright (C) 2010 by Uwe Kleine-König <u.kleine-koenig@pengutronix.de> import getopt import re import os import subprocess import sys # This prevents including a timestamp in the .config which makes comparing a # bit easier. os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please' re_interesting = re.compile(r'^(# )?CONFIG_') opts, args = getopt.getopt(sys.argv[1:], '', ['arch=', 'src=']) src = '' arch = 'arm' for o, a in opts: if o == '--arch': arch = a elif o == '--src': src = a configdir = os.path.join(src, 'arch', arch, 'configs') def all_defconfigs(): lc = len(configdir) for root, dirs, files in os.walk(configdir): root = root[lc + 1:] for f in filter(lambda s: s.endswith('_defconfig'), files): yield os.path.join(root, f) if not args: args = all_defconfigs() for target in args: defconfig_src = os.path.join(configdir, target) subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) origconfig = list(open('.config')) config = list(origconfig) config_size = os.stat('.config').st_size i = 0 while i < len(config): mo = re_interesting.match(config[i]) if mo: defconfig = open(defconfig_src, 'w') defconfig.writelines(config[:i]) defconfig.writelines(config[i + 1:]) defconfig.close() subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig: print '-%s' % config[i][:-1] del config[i] else: print ' %s' % config[i][:-1] i += 1 else: del config[i] defconfig = open(defconfig_src, 'w') defconfig.writelines(config) defconfig.close() ^ permalink raw reply [flat|nested] 133+ messages in thread
* optimized script [Was: ARM defconfig files] @ 2010-07-13 8:07 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-13 8:07 UTC (permalink / raw) To: linux-arm-kernel Hello, On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-K?nig wrote: > Hi > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > <torvalds@linux-foundation.org> wrote: > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > >> I think Uwe could provide his script and add it to the kernel tree. > > >> Then all architectures could benefit from it. ?Having the defconfig > > >> files contain only those options which are different from the defaults > > >> is certainly more readable, even on x86. > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > people actually using the script, and refusing to apply patches that > > > re-introduce the whole big thing. > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > I think we can do the same. After the defconfigs are trimmed, I > > certainly won't pick up any more full defconfigs. > I just restarted my script on the powerpc defconfigs basing on rc5, I > assume they complete in a few days time. So Stephen was faster than me. I don't know yet how he optimised my script, meanwhile I put some efforts into it, too by just checking lines that match "^(# )?CONFIG_". Find it attached. I will start to reduce the remaining configs (i.e. all but arm and powerpc). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | -------------- next part -------------- #! /usr/bin/env python # vim: set fileencoding=utf-8 : # Copyright (C) 2010 by Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> import getopt import re import os import subprocess import sys # This prevents including a timestamp in the .config which makes comparing a # bit easier. os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please' re_interesting = re.compile(r'^(# )?CONFIG_') opts, args = getopt.getopt(sys.argv[1:], '', ['arch=', 'src=']) src = '' arch = 'arm' for o, a in opts: if o == '--arch': arch = a elif o == '--src': src = a configdir = os.path.join(src, 'arch', arch, 'configs') def all_defconfigs(): lc = len(configdir) for root, dirs, files in os.walk(configdir): root = root[lc + 1:] for f in filter(lambda s: s.endswith('_defconfig'), files): yield os.path.join(root, f) if not args: args = all_defconfigs() for target in args: defconfig_src = os.path.join(configdir, target) subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) origconfig = list(open('.config')) config = list(origconfig) config_size = os.stat('.config').st_size i = 0 while i < len(config): mo = re_interesting.match(config[i]) if mo: defconfig = open(defconfig_src, 'w') defconfig.writelines(config[:i]) defconfig.writelines(config[i + 1:]) defconfig.close() subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig: print '-%s' % config[i][:-1] del config[i] else: print ' %s' % config[i][:-1] i += 1 else: del config[i] defconfig = open(defconfig_src, 'w') defconfig.writelines(config) defconfig.close() ^ permalink raw reply [flat|nested] 133+ messages in thread
* optimized script [Was: ARM defconfig files] @ 2010-07-13 8:07 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-13 8:07 UTC (permalink / raw) To: Linus Torvalds Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux, Nicolas Pitre, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, Eric Miao, Olof Johansson, linux-omap, linuxppc-dev, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 1548 bytes --] Hello, On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote: > Hi > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > <torvalds@linux-foundation.org> wrote: > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > >> I think Uwe could provide his script and add it to the kernel tree. > > >> Then all architectures could benefit from it. Having the defconfig > > >> files contain only those options which are different from the defaults > > >> is certainly more readable, even on x86. > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > people actually using the script, and refusing to apply patches that > > > re-introduce the whole big thing. > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > I think we can do the same. After the defconfigs are trimmed, I > > certainly won't pick up any more full defconfigs. > I just restarted my script on the powerpc defconfigs basing on rc5, I > assume they complete in a few days time. So Stephen was faster than me. I don't know yet how he optimised my script, meanwhile I put some efforts into it, too by just checking lines that match "^(# )?CONFIG_". Find it attached. I will start to reduce the remaining configs (i.e. all but arm and powerpc). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | [-- Attachment #2: reduce_defconfig --] [-- Type: text/plain, Size: 1899 bytes --] #! /usr/bin/env python # vim: set fileencoding=utf-8 : # Copyright (C) 2010 by Uwe Kleine-König <u.kleine-koenig@pengutronix.de> import getopt import re import os import subprocess import sys # This prevents including a timestamp in the .config which makes comparing a # bit easier. os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please' re_interesting = re.compile(r'^(# )?CONFIG_') opts, args = getopt.getopt(sys.argv[1:], '', ['arch=', 'src=']) src = '' arch = 'arm' for o, a in opts: if o == '--arch': arch = a elif o == '--src': src = a configdir = os.path.join(src, 'arch', arch, 'configs') def all_defconfigs(): lc = len(configdir) for root, dirs, files in os.walk(configdir): root = root[lc + 1:] for f in filter(lambda s: s.endswith('_defconfig'), files): yield os.path.join(root, f) if not args: args = all_defconfigs() for target in args: defconfig_src = os.path.join(configdir, target) subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) origconfig = list(open('.config')) config = list(origconfig) config_size = os.stat('.config').st_size i = 0 while i < len(config): mo = re_interesting.match(config[i]) if mo: defconfig = open(defconfig_src, 'w') defconfig.writelines(config[:i]) defconfig.writelines(config[i + 1:]) defconfig.close() subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig: print '-%s' % config[i][:-1] del config[i] else: print ' %s' % config[i][:-1] i += 1 else: del config[i] defconfig = open(defconfig_src, 'w') defconfig.writelines(config) defconfig.close() ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: optimized script [Was: ARM defconfig files] 2010-07-13 8:07 ` Uwe Kleine-König (?) (?) @ 2010-07-13 18:04 ` Olof Johansson -1 siblings, 0 replies; 133+ messages in thread From: Olof Johansson @ 2010-07-13 18:04 UTC (permalink / raw) To: Uwe Kleine-König Cc: Linus Torvalds, Grant Likely, Nicolas Pitre, Daniel Walker, Russell King - ARM Linux, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, linux-omap, Eric Miao, linux-arm-kernel, Stephen Rothwell, Benjamin Herrenschmidt, linuxppc-dev On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote: > Hello, > > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote: > > Hi > > > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > > <torvalds@linux-foundation.org> wrote: > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > > >> I think Uwe could provide his script and add it to the kernel tree. > > > >> Then all architectures could benefit from it. Having the defconfig > > > >> files contain only those options which are different from the defaults > > > >> is certainly more readable, even on x86. > > > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > > people actually using the script, and refusing to apply patches that > > > > re-introduce the whole big thing. > > > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > > I think we can do the same. After the defconfigs are trimmed, I > > > certainly won't pick up any more full defconfigs. > > I just restarted my script on the powerpc defconfigs basing on rc5, I > > assume they complete in a few days time. > So Stephen was faster than me. I don't know yet how he optimised my > script, meanwhile I put some efforts into it, too by just checking lines > that match "^(# )?CONFIG_". > > Find it attached. > > I will start to reduce the remaining configs (i.e. all but arm and > powerpc). I added just a simple heuristic: If I could remove a line, I attempted to remove twice the amount next time around (and fall back to 1 if it failed). I.e. main loop: i = 0 lines = 1 while i < len(config): print 'test for %r + %d' % (config[i], lines) defconfig = open(defconfig_src, 'w') defconfig.writelines(config[:i]) defconfig.writelines(config[i + lines:]) defconfig.close() subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig: del config[i:i+lines] lines *= 2 else: if lines > 1: lines = 1 else: i += 1 I didn't measure what the actual improvement was, but I saw a fair amount of 2/4/8-attempts passing, so I let it run. Stephen beat me to posting the resulting patch though. :P While this script is great, it is somewhat painful to run given that it attempts one config per line. Even on a fast machine that tends to take a while. -Olof ^ permalink raw reply [flat|nested] 133+ messages in thread
* optimized script [Was: ARM defconfig files] @ 2010-07-13 18:04 ` Olof Johansson 0 siblings, 0 replies; 133+ messages in thread From: Olof Johansson @ 2010-07-13 18:04 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-K?nig wrote: > Hello, > > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-K?nig wrote: > > Hi > > > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > > <torvalds@linux-foundation.org> wrote: > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > > >> I think Uwe could provide his script and add it to the kernel tree. > > > >> Then all architectures could benefit from it. ?Having the defconfig > > > >> files contain only those options which are different from the defaults > > > >> is certainly more readable, even on x86. > > > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > > people actually using the script, and refusing to apply patches that > > > > re-introduce the whole big thing. > > > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > > I think we can do the same. After the defconfigs are trimmed, I > > > certainly won't pick up any more full defconfigs. > > I just restarted my script on the powerpc defconfigs basing on rc5, I > > assume they complete in a few days time. > So Stephen was faster than me. I don't know yet how he optimised my > script, meanwhile I put some efforts into it, too by just checking lines > that match "^(# )?CONFIG_". > > Find it attached. > > I will start to reduce the remaining configs (i.e. all but arm and > powerpc). I added just a simple heuristic: If I could remove a line, I attempted to remove twice the amount next time around (and fall back to 1 if it failed). I.e. main loop: i = 0 lines = 1 while i < len(config): print 'test for %r + %d' % (config[i], lines) defconfig = open(defconfig_src, 'w') defconfig.writelines(config[:i]) defconfig.writelines(config[i + lines:]) defconfig.close() subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig: del config[i:i+lines] lines *= 2 else: if lines > 1: lines = 1 else: i += 1 I didn't measure what the actual improvement was, but I saw a fair amount of 2/4/8-attempts passing, so I let it run. Stephen beat me to posting the resulting patch though. :P While this script is great, it is somewhat painful to run given that it attempts one config per line. Even on a fast machine that tends to take a while. -Olof ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: optimized script [Was: ARM defconfig files] @ 2010-07-13 18:04 ` Olof Johansson 0 siblings, 0 replies; 133+ messages in thread From: Olof Johansson @ 2010-07-13 18:04 UTC (permalink / raw) To: Uwe Kleine-König Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux, Nicolas Pitre, Kevin Hilman, linux-arm-msm, linuxppc-dev, Linux Kernel Mailing List, Eric Miao, linux-omap, Linus Torvalds, linux-arm-kernel On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote: > Hello, > > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote: > > Hi > > > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > > <torvalds@linux-foundation.org> wrote: > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > > >> I think Uwe could provide his script and add it to the kernel tree. > > > >> Then all architectures could benefit from it. Having the defconfig > > > >> files contain only those options which are different from the defaults > > > >> is certainly more readable, even on x86. > > > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > > people actually using the script, and refusing to apply patches that > > > > re-introduce the whole big thing. > > > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > > I think we can do the same. After the defconfigs are trimmed, I > > > certainly won't pick up any more full defconfigs. > > I just restarted my script on the powerpc defconfigs basing on rc5, I > > assume they complete in a few days time. > So Stephen was faster than me. I don't know yet how he optimised my > script, meanwhile I put some efforts into it, too by just checking lines > that match "^(# )?CONFIG_". > > Find it attached. > > I will start to reduce the remaining configs (i.e. all but arm and > powerpc). I added just a simple heuristic: If I could remove a line, I attempted to remove twice the amount next time around (and fall back to 1 if it failed). I.e. main loop: i = 0 lines = 1 while i < len(config): print 'test for %r + %d' % (config[i], lines) defconfig = open(defconfig_src, 'w') defconfig.writelines(config[:i]) defconfig.writelines(config[i + lines:]) defconfig.close() subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig: del config[i:i+lines] lines *= 2 else: if lines > 1: lines = 1 else: i += 1 I didn't measure what the actual improvement was, but I saw a fair amount of 2/4/8-attempts passing, so I let it run. Stephen beat me to posting the resulting patch though. :P While this script is great, it is somewhat painful to run given that it attempts one config per line. Even on a fast machine that tends to take a while. -Olof ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: optimized script [Was: ARM defconfig files] @ 2010-07-13 18:04 ` Olof Johansson 0 siblings, 0 replies; 133+ messages in thread From: Olof Johansson @ 2010-07-13 18:04 UTC (permalink / raw) To: Uwe Kleine-König Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux, Nicolas Pitre, Kevin Hilman, linux-arm-msm, linuxppc-dev, Linux Kernel Mailing List, Grant Likely, Eric Miao, Benjamin Herrenschmidt, linux-omap, Linus Torvalds, linux-arm-kernel On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote: > Hello, > > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote: > > Hi > > > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > > <torvalds@linux-foundation.org> wrote: > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > > >> I think Uwe could provide his script and add it to the kernel tree. > > > >> Then all architectures could benefit from it. Having the defconfig > > > >> files contain only those options which are different from the defaults > > > >> is certainly more readable, even on x86. > > > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > > people actually using the script, and refusing to apply patches that > > > > re-introduce the whole big thing. > > > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > > I think we can do the same. After the defconfigs are trimmed, I > > > certainly won't pick up any more full defconfigs. > > I just restarted my script on the powerpc defconfigs basing on rc5, I > > assume they complete in a few days time. > So Stephen was faster than me. I don't know yet how he optimised my > script, meanwhile I put some efforts into it, too by just checking lines > that match "^(# )?CONFIG_". > > Find it attached. > > I will start to reduce the remaining configs (i.e. all but arm and > powerpc). I added just a simple heuristic: If I could remove a line, I attempted to remove twice the amount next time around (and fall back to 1 if it failed). I.e. main loop: i = 0 lines = 1 while i < len(config): print 'test for %r + %d' % (config[i], lines) defconfig = open(defconfig_src, 'w') defconfig.writelines(config[:i]) defconfig.writelines(config[i + lines:]) defconfig.close() subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig: del config[i:i+lines] lines *= 2 else: if lines > 1: lines = 1 else: i += 1 I didn't measure what the actual improvement was, but I saw a fair amount of 2/4/8-attempts passing, so I let it run. Stephen beat me to posting the resulting patch though. :P While this script is great, it is somewhat painful to run given that it attempts one config per line. Even on a fast machine that tends to take a while. -Olof ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: optimized script [Was: ARM defconfig files] 2010-07-13 18:04 ` Olof Johansson (?) @ 2010-07-13 23:39 ` Nicolas Pitre -1 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-13 23:39 UTC (permalink / raw) To: Olof Johansson Cc: Uwe Kleine-König, Linus Torvalds, Grant Likely, Daniel Walker, Russell King - ARM Linux, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, linux-omap, Eric Miao, linux-arm-kernel, Stephen Rothwell, Benjamin Herrenschmidt, linuxppc-dev [-- Attachment #1: Type: TEXT/PLAIN, Size: 2203 bytes --] On Tue, 13 Jul 2010, Olof Johansson wrote: > On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote: > > Hello, > > > > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote: > > > Hi > > > > > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > > > <torvalds@linux-foundation.org> wrote: > > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > > > >> I think Uwe could provide his script and add it to the kernel tree. > > > > >> Then all architectures could benefit from it. Having the defconfig > > > > >> files contain only those options which are different from the defaults > > > > >> is certainly more readable, even on x86. > > > > > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > > > people actually using the script, and refusing to apply patches that > > > > > re-introduce the whole big thing. > > > > > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > > > I think we can do the same. After the defconfigs are trimmed, I > > > > certainly won't pick up any more full defconfigs. > > > I just restarted my script on the powerpc defconfigs basing on rc5, I > > > assume they complete in a few days time. > > So Stephen was faster than me. I don't know yet how he optimised my > > script, meanwhile I put some efforts into it, too by just checking lines > > that match "^(# )?CONFIG_". > > > > Find it attached. > > > > I will start to reduce the remaining configs (i.e. all but arm and > > powerpc). > > I added just a simple heuristic: If I could remove a line, I attempted > to remove twice the amount next time around (and fall back to 1 if it failed). > [...] > > While this script is great, it is somewhat painful to run given that it > attempts one config per line. Even on a fast machine that tends to take > a while. The optimal solution is to add that .config reduction ability straight into the Kconfig parser (scripts/kconfig/*). There you can find out right away what are the non default state for each config option without actually trying them out one by one. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* optimized script [Was: ARM defconfig files] @ 2010-07-13 23:39 ` Nicolas Pitre 0 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-13 23:39 UTC (permalink / raw) To: linux-arm-kernel On Tue, 13 Jul 2010, Olof Johansson wrote: > On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-K?nig wrote: > > Hello, > > > > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-K?nig wrote: > > > Hi > > > > > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > > > <torvalds@linux-foundation.org> wrote: > > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > > > >> I think Uwe could provide his script and add it to the kernel tree. > > > > >> Then all architectures could benefit from it. ?Having the defconfig > > > > >> files contain only those options which are different from the defaults > > > > >> is certainly more readable, even on x86. > > > > > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > > > people actually using the script, and refusing to apply patches that > > > > > re-introduce the whole big thing. > > > > > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > > > I think we can do the same. After the defconfigs are trimmed, I > > > > certainly won't pick up any more full defconfigs. > > > I just restarted my script on the powerpc defconfigs basing on rc5, I > > > assume they complete in a few days time. > > So Stephen was faster than me. I don't know yet how he optimised my > > script, meanwhile I put some efforts into it, too by just checking lines > > that match "^(# )?CONFIG_". > > > > Find it attached. > > > > I will start to reduce the remaining configs (i.e. all but arm and > > powerpc). > > I added just a simple heuristic: If I could remove a line, I attempted > to remove twice the amount next time around (and fall back to 1 if it failed). > [...] > > While this script is great, it is somewhat painful to run given that it > attempts one config per line. Even on a fast machine that tends to take > a while. The optimal solution is to add that .config reduction ability straight into the Kconfig parser (scripts/kconfig/*). There you can find out right away what are the non default state for each config option without actually trying them out one by one. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: optimized script [Was: ARM defconfig files] @ 2010-07-13 23:39 ` Nicolas Pitre 0 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-13 23:39 UTC (permalink / raw) To: Olof Johansson Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux, Kevin Hilman, linux-arm-msm, linuxppc-dev, Linux Kernel Mailing List, Eric Miao, Uwe Kleine-König, linux-omap, Linus Torvalds, linux-arm-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 2203 bytes --] On Tue, 13 Jul 2010, Olof Johansson wrote: > On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote: > > Hello, > > > > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote: > > > Hi > > > > > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds > > > > <torvalds@linux-foundation.org> wrote: > > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > > > >> I think Uwe could provide his script and add it to the kernel tree. > > > > >> Then all architectures could benefit from it. Having the defconfig > > > > >> files contain only those options which are different from the defaults > > > > >> is certainly more readable, even on x86. > > > > > > > > > > Quite possible. But maintainers would need to be on the lookout of > > > > > people actually using the script, and refusing to apply patches that > > > > > re-introduce the whole big thing. > > > > > > > > I can (partially) speak for powerpc. If ARM uses this approach, then > > > > I think we can do the same. After the defconfigs are trimmed, I > > > > certainly won't pick up any more full defconfigs. > > > I just restarted my script on the powerpc defconfigs basing on rc5, I > > > assume they complete in a few days time. > > So Stephen was faster than me. I don't know yet how he optimised my > > script, meanwhile I put some efforts into it, too by just checking lines > > that match "^(# )?CONFIG_". > > > > Find it attached. > > > > I will start to reduce the remaining configs (i.e. all but arm and > > powerpc). > > I added just a simple heuristic: If I could remove a line, I attempted > to remove twice the amount next time around (and fall back to 1 if it failed). > [...] > > While this script is great, it is somewhat painful to run given that it > attempts one config per line. Even on a fast machine that tends to take > a while. The optimal solution is to add that .config reduction ability straight into the Kconfig parser (scripts/kconfig/*). There you can find out right away what are the non default state for each config option without actually trying them out one by one. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-13 7:07 ` Uwe Kleine-König (?) @ 2010-07-13 18:32 ` Grant Likely -1 siblings, 0 replies; 133+ messages in thread From: Grant Likely @ 2010-07-13 18:32 UTC (permalink / raw) To: Uwe Kleine-König Cc: Linus Torvalds, Nicolas Pitre, Daniel Walker, Russell King - ARM Linux, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, linux-omap, Eric Miao, linux-arm-kernel 2010/7/13 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: > Hi > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: >> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds >> <torvalds@linux-foundation.org> wrote: >> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> >> I think Uwe could provide his script and add it to the kernel tree. >> >> Then all architectures could benefit from it. Having the defconfig >> >> files contain only those options which are different from the defaults >> >> is certainly more readable, even on x86. >> > >> > Quite possible. But maintainers would need to be on the lookout of >> > people actually using the script, and refusing to apply patches that >> > re-introduce the whole big thing. >> >> I can (partially) speak for powerpc. If ARM uses this approach, then >> I think we can do the same. After the defconfigs are trimmed, I >> certainly won't pick up any more full defconfigs. > I just restarted my script on the powerpc defconfigs basing on rc5, I > assume they complete in a few days time. > >> Of course, I'm also operating under the assumption that this is a >> temporary measure until one of the better solutions is implemented. > ack > >> I >> do suspect that the trimmed defconfigs will tend to be unstable and >> will still require manual maintenance. I think the Kconfig fragments >> approach is the most promising if the dependencies issue can be >> solved. > I don't understand what you mean with unstable here. They are sensible > to changed defaults in the Kconfig files which you can consider to be > good or bad. With the trimmed config, changes to default settings on config items will immediately picked up regardless of whether or not it was wanted, and potentially disabling things that were explicitly selected in defconfig. But thinking about it more, that isn't really any worse than the old situation where defconfigs always override Kconfig defaults. So either way, defconfigs are simply a broken concept. > And ack, I like the Kconfig approach, too. Yeah, the problem goes away with Kconfig fragments. A programmer can then explicitly state which CONFIG values need to be overridden. g. ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-13 18:32 ` Grant Likely 0 siblings, 0 replies; 133+ messages in thread From: Grant Likely @ 2010-07-13 18:32 UTC (permalink / raw) To: linux-arm-kernel 2010/7/13 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>: > Hi > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: >> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds >> <torvalds@linux-foundation.org> wrote: >> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> >> I think Uwe could provide his script and add it to the kernel tree. >> >> Then all architectures could benefit from it. ?Having the defconfig >> >> files contain only those options which are different from the defaults >> >> is certainly more readable, even on x86. >> > >> > Quite possible. But maintainers would need to be on the lookout of >> > people actually using the script, and refusing to apply patches that >> > re-introduce the whole big thing. >> >> I can (partially) speak for powerpc. ?If ARM uses this approach, then >> I think we can do the same. ?After the defconfigs are trimmed, I >> certainly won't pick up any more full defconfigs. > I just restarted my script on the powerpc defconfigs basing on rc5, I > assume they complete in a few days time. > >> Of course, I'm also operating under the assumption that this is a >> temporary measure until one of the better solutions is implemented. > ack > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?I >> do suspect that the trimmed defconfigs will tend to be unstable and >> will still require manual maintenance. ?I think the Kconfig fragments >> approach is the most promising if the dependencies issue can be >> solved. > I don't understand what you mean with unstable here. ?They are sensible > to changed defaults in the Kconfig files which you can consider to be > good or bad. With the trimmed config, changes to default settings on config items will immediately picked up regardless of whether or not it was wanted, and potentially disabling things that were explicitly selected in defconfig. But thinking about it more, that isn't really any worse than the old situation where defconfigs always override Kconfig defaults. So either way, defconfigs are simply a broken concept. > And ack, I like the Kconfig approach, too. Yeah, the problem goes away with Kconfig fragments. A programmer can then explicitly state which CONFIG values need to be overridden. g. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-13 18:32 ` Grant Likely 0 siblings, 0 replies; 133+ messages in thread From: Grant Likely @ 2010-07-13 18:32 UTC (permalink / raw) To: Uwe Kleine-König Cc: Daniel Walker, Russell King - ARM Linux, Nicolas Pitre, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, Eric Miao, linux-omap, Linus Torvalds, linux-arm-kernel 2010/7/13 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: > Hi > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: >> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds >> <torvalds@linux-foundation.org> wrote: >> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> >> I think Uwe could provide his script and add it to the kernel tree. >> >> Then all architectures could benefit from it. Having the defconfig >> >> files contain only those options which are different from the defaults >> >> is certainly more readable, even on x86. >> > >> > Quite possible. But maintainers would need to be on the lookout of >> > people actually using the script, and refusing to apply patches that >> > re-introduce the whole big thing. >> >> I can (partially) speak for powerpc. If ARM uses this approach, then >> I think we can do the same. After the defconfigs are trimmed, I >> certainly won't pick up any more full defconfigs. > I just restarted my script on the powerpc defconfigs basing on rc5, I > assume they complete in a few days time. > >> Of course, I'm also operating under the assumption that this is a >> temporary measure until one of the better solutions is implemented. > ack > >> I >> do suspect that the trimmed defconfigs will tend to be unstable and >> will still require manual maintenance. I think the Kconfig fragments >> approach is the most promising if the dependencies issue can be >> solved. > I don't understand what you mean with unstable here. They are sensible > to changed defaults in the Kconfig files which you can consider to be > good or bad. With the trimmed config, changes to default settings on config items will immediately picked up regardless of whether or not it was wanted, and potentially disabling things that were explicitly selected in defconfig. But thinking about it more, that isn't really any worse than the old situation where defconfigs always override Kconfig defaults. So either way, defconfigs are simply a broken concept. > And ack, I like the Kconfig approach, too. Yeah, the problem goes away with Kconfig fragments. A programmer can then explicitly state which CONFIG values need to be overridden. g. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 19:34 ` Linus Torvalds @ 2010-07-12 19:59 ` Uwe Kleine-König -1 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-12 19:59 UTC (permalink / raw) To: Linus Torvalds Cc: Nicolas Pitre, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap [-- Attachment #1: Type: text/plain, Size: 3824 bytes --] Hi Linus, On Mon, Jul 12, 2010 at 12:34:59PM -0700, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > >> > >> Put another way: I realize that fairly late in the -rc series is > >> actually a really good time to do this, rather than during the merge > >> window itself when things are in flux. However, while it would be a > >> good time to pull this for that reason, it's also a _horrible_ time to > >> pull if it then regresses the defconfig uses, or if it causes horrible > >> problems for linux-next merging etc. > > > > This cannot be any worse than wholesale removal of those files as you > > were contemplating at some point. Furthermore, on ARM we have someone > > providing automatic rebuild of all defconfigs already, so any serious > > issue should be noticed right away. > > You aren't really answering the question. The thing is, the wholesale > removal wouldn't happen during the late -rc anyway, and it wouldn't > cause any merge issues (merge conflicts where the file is just to be > removed are trivial to take care of). > > So I'm really asking about the issue of "how does this work during the > late -rc phase". Where the _timing_ is the important thing. > > Because I could as easily pull after 2.6.35 is out. That has it's own > downsides (with all the merging going on), but at the same time, it's > clearly the right time for a large change. I hoped you to pull this in during the merge window, but doing it now is OK for me, too. > So when I ask about timing and "how does this work in late -rc", it's > really about how safe it is to do now. Because if it isn't very > obviously safe, I can't pull it. > > One part of the "obviously safe" thing is verification for each > defconfig file that the end result is identical with the reduced > version. Uwe implied that it was, and that was clearly the intention, > but was there some explicit verification that yes, the > before-and-after configurations are 100% the same? I'm pretty sure it's 100% save as I only kick a line in the defconfig if the result doesn't change. Well, modulo bugs in my script. But now that it's public you can convince yourself it's (hopefully) correct. > Also, I assume that while it's _mostly_ a transparent change to users, > it does require that people do "make oldconfig" with the reduced > defconfig file first, in order to avoid having to answer with the > defaults. No? No, $(make ..._defconfig) is enough to get the full .config. > And the reduced defconfig files obviously do depend on > the default in the Kconfig files themselves, so it does have that kind > of fairly subtle semantic change that may not be entirely obvious or > easy to notice. Right. > So from a timing standpoint, I just want to be convinced that "late > -rc" really is the right thing. I'm not entirely sure it is, even > though I do see advantages. > > > I think Uwe could provide his script and add it to the kernel tree. > > Then all architectures could benefit from it. Having the defconfig > > files contain only those options which are different from the defaults > > is certainly more readable, even on x86. > > Quite possible. But maintainers would need to be on the lookout of > people actually using the script, and refusing to apply patches that > re-introduce the whole big thing. > > I also haven't actually seen the script - I don't think Uwe ever > posted it - so maybe it's some very fragile thing. Hard to judge on no > real information ;^p See attachment. It's just: for each line: kick $line if $(make ..._defconfig) results in the same config without $line Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | [-- Attachment #2: reduce_defconfig --] [-- Type: text/plain, Size: 1206 bytes --] #! /usr/bin/env python # vim: set fileencoding=utf-8 : # Copyright (C) 2010 by Uwe Kleine-König <u.kleine-koenig@pengutronix.de> import re import subprocess import os import sys # This prevents including a timestamp in the .config which makes comparing a # bit easier. os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please' # XXX: get these using getopt kernel_tree = '' # os.path.join(os.environ['HOME'], 'gsrc', 'linux-2.6') arch = 'arm' target = sys.argv[1] defconfig_src = os.path.join(kernel_tree, 'arch/%s/configs/%s' % (arch, target)) subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) origconfig = list(open('.config')) config = list(origconfig) config_size = os.stat('.config').st_size i = 0 while i < len(config): print 'test for %r' % config[i] defconfig = open(defconfig_src, 'w') defconfig.writelines(config[:i]) defconfig.writelines(config[i + 1:]) defconfig.close() subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig: del config[i] else: i += 1 defconfig = open(defconfig_src, 'w') defconfig.writelines(config) defconfig.close() ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 19:59 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-12 19:59 UTC (permalink / raw) To: linux-arm-kernel Hi Linus, On Mon, Jul 12, 2010 at 12:34:59PM -0700, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > >> > >> ? ?Put another way: I realize that fairly late in the -rc series is > >> actually a really good time to do this, rather than during the merge > >> window itself when things are in flux. However, while it would be a > >> good time to pull this for that reason, it's also a _horrible_ time to > >> pull if it then regresses the defconfig uses, or if it causes horrible > >> problems for linux-next merging etc. > > > > This cannot be any worse than wholesale removal of those files as you > > were contemplating at some point. ?Furthermore, on ARM we have someone > > providing automatic rebuild of all defconfigs already, so any serious > > issue should be noticed right away. > > You aren't really answering the question. The thing is, the wholesale > removal wouldn't happen during the late -rc anyway, and it wouldn't > cause any merge issues (merge conflicts where the file is just to be > removed are trivial to take care of). > > So I'm really asking about the issue of "how does this work during the > late -rc phase". Where the _timing_ is the important thing. > > Because I could as easily pull after 2.6.35 is out. That has it's own > downsides (with all the merging going on), but at the same time, it's > clearly the right time for a large change. I hoped you to pull this in during the merge window, but doing it now is OK for me, too. > So when I ask about timing and "how does this work in late -rc", it's > really about how safe it is to do now. Because if it isn't very > obviously safe, I can't pull it. > > One part of the "obviously safe" thing is verification for each > defconfig file that the end result is identical with the reduced > version. Uwe implied that it was, and that was clearly the intention, > but was there some explicit verification that yes, the > before-and-after configurations are 100% the same? I'm pretty sure it's 100% save as I only kick a line in the defconfig if the result doesn't change. Well, modulo bugs in my script. But now that it's public you can convince yourself it's (hopefully) correct. > Also, I assume that while it's _mostly_ a transparent change to users, > it does require that people do "make oldconfig" with the reduced > defconfig file first, in order to avoid having to answer with the > defaults. No? No, $(make ..._defconfig) is enough to get the full .config. > And the reduced defconfig files obviously do depend on > the default in the Kconfig files themselves, so it does have that kind > of fairly subtle semantic change that may not be entirely obvious or > easy to notice. Right. > So from a timing standpoint, I just want to be convinced that "late > -rc" really is the right thing. I'm not entirely sure it is, even > though I do see advantages. > > > I think Uwe could provide his script and add it to the kernel tree. > > Then all architectures could benefit from it. ?Having the defconfig > > files contain only those options which are different from the defaults > > is certainly more readable, even on x86. > > Quite possible. But maintainers would need to be on the lookout of > people actually using the script, and refusing to apply patches that > re-introduce the whole big thing. > > I also haven't actually seen the script - I don't think Uwe ever > posted it - so maybe it's some very fragile thing. Hard to judge on no > real information ;^p See attachment. It's just: for each line: kick $line if $(make ..._defconfig) results in the same config without $line Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | -------------- next part -------------- #! /usr/bin/env python # vim: set fileencoding=utf-8 : # Copyright (C) 2010 by Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> import re import subprocess import os import sys # This prevents including a timestamp in the .config which makes comparing a # bit easier. os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please' # XXX: get these using getopt kernel_tree = '' # os.path.join(os.environ['HOME'], 'gsrc', 'linux-2.6') arch = 'arm' target = sys.argv[1] defconfig_src = os.path.join(kernel_tree, 'arch/%s/configs/%s' % (arch, target)) subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) origconfig = list(open('.config')) config = list(origconfig) config_size = os.stat('.config').st_size i = 0 while i < len(config): print 'test for %r' % config[i] defconfig = open(defconfig_src, 'w') defconfig.writelines(config[:i]) defconfig.writelines(config[i + 1:]) defconfig.close() subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target]) if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig: del config[i] else: i += 1 defconfig = open(defconfig_src, 'w') defconfig.writelines(config) defconfig.close() ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 19:34 ` Linus Torvalds @ 2010-07-12 20:14 ` Nicolas Pitre -1 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 20:14 UTC (permalink / raw) To: Linus Torvalds Cc: Uwe Kleine-König, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap [-- Attachment #1: Type: TEXT/PLAIN, Size: 5449 bytes --] On Mon, 12 Jul 2010, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > >> > >> Put another way: I realize that fairly late in the -rc series is > >> actually a really good time to do this, rather than during the merge > >> window itself when things are in flux. However, while it would be a > >> good time to pull this for that reason, it's also a _horrible_ time to > >> pull if it then regresses the defconfig uses, or if it causes horrible > >> problems for linux-next merging etc. > > > > This cannot be any worse than wholesale removal of those files as you > > were contemplating at some point. Furthermore, on ARM we have someone > > providing automatic rebuild of all defconfigs already, so any serious > > issue should be noticed right away. > > You aren't really answering the question. The thing is, the wholesale > removal wouldn't happen during the late -rc anyway, and it wouldn't > cause any merge issues (merge conflicts where the file is just to be > removed are trivial to take care of). I'll answer for myself only. Others are free to pitch in if they have a different opinion. Since this issue came up, RMK refused to merge any changes to the arch/arm/configs directory. Therefore a lot of those files aren't quite up to date anymore anyway. We simply skipped the usual defconfig updates that used to be sent around -rc4. And that's for the few defconfig files that people cared to update. A bunch of less frequently used targets are probably out of date since many kernel versions ago. Those files are mainly used as a convenience for build testing. We tend to cram as many profiles together as we can to limit the number of different test builds. The remaining files are (supposed to be) incompatible configurations. So I doubt anyone is using them verbatim for deployed systems. If anything they should be reference configurations not final product ones. > So I'm really asking about the issue of "how does this work during the > late -rc phase". Where the _timing_ is the important thing. Given what I said above, I think that: 1) Those files aren't critical. They're damn useful indeed, but a glitch in a defconfig file is far from being as important as a glitch in the very code they refer to. So I don't think this is all that critical if the pull is applied late in the -rc period. 2) Doing it sooner rather than later is IMHO the best thing to do. At least we could now focus on maintaining and even improving on that state rather than going on in circles wondering what to do with it. People would be able to think about how to update their defconfig files in the new form now instead of simply not updating it at all as it has been the case for a while until something happens. So to me this is all in favor for a merge before next merge window. During the merge window this would create even more headaches. > So when I ask about timing and "how does this work in late -rc", it's > really about how safe it is to do now. Because if it isn't very > obviously safe, I can't pull it. As I said above, those files aren't that critical and no one should end up in trouble if something is not exactly right after this merge. So this makes it pretty safe to me. > One part of the "obviously safe" thing is verification for each > defconfig file that the end result is identical with the reduced > version. Uwe implied that it was, and that was clearly the intention, > but was there some explicit verification that yes, the > before-and-after configurations are 100% the same? I'll let Uwe answer this. > Also, I assume that while it's _mostly_ a transparent change to users, > it does require that people do "make oldconfig" with the reduced > defconfig file first, in order to avoid having to answer with the > defaults. No? And the reduced defconfig files obviously do depend on > the default in the Kconfig files themselves, so it does have that kind > of fairly subtle semantic change that may not be entirely obvious or > easy to notice. That is going to be the case regardless of the merge timing for this. > So from a timing standpoint, I just want to be convinced that "late > -rc" really is the right thing. I'm not entirely sure it is, even > though I do see advantages. I do too. At least this is positive progress for some bad issue that no one could ever get very passionate about. Better keep the momentum. > > I think Uwe could provide his script and add it to the kernel tree. > > Then all architectures could benefit from it. Having the defconfig > > files contain only those options which are different from the defaults > > is certainly more readable, even on x86. > > Quite possible. But maintainers would need to be on the lookout of > people actually using the script, and refusing to apply patches that > re-introduce the whole big thing. Pretty easy to see on the diffstat graph. Anyway, I'm sure once the script is available then an army of kernel janitors will be busy trying to find any transgressor. > I also haven't actually seen the script - I don't think Uwe ever > posted it - so maybe it's some very fragile thing. Hard to judge on no > real information ;^p I'm sure the script was quickly cobbled together as a proof of concept. But once this defconfig reduction goes in then interest for a solid script should raise significantly. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 20:14 ` Nicolas Pitre 0 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 20:14 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > >> > >> ? ?Put another way: I realize that fairly late in the -rc series is > >> actually a really good time to do this, rather than during the merge > >> window itself when things are in flux. However, while it would be a > >> good time to pull this for that reason, it's also a _horrible_ time to > >> pull if it then regresses the defconfig uses, or if it causes horrible > >> problems for linux-next merging etc. > > > > This cannot be any worse than wholesale removal of those files as you > > were contemplating at some point. ?Furthermore, on ARM we have someone > > providing automatic rebuild of all defconfigs already, so any serious > > issue should be noticed right away. > > You aren't really answering the question. The thing is, the wholesale > removal wouldn't happen during the late -rc anyway, and it wouldn't > cause any merge issues (merge conflicts where the file is just to be > removed are trivial to take care of). I'll answer for myself only. Others are free to pitch in if they have a different opinion. Since this issue came up, RMK refused to merge any changes to the arch/arm/configs directory. Therefore a lot of those files aren't quite up to date anymore anyway. We simply skipped the usual defconfig updates that used to be sent around -rc4. And that's for the few defconfig files that people cared to update. A bunch of less frequently used targets are probably out of date since many kernel versions ago. Those files are mainly used as a convenience for build testing. We tend to cram as many profiles together as we can to limit the number of different test builds. The remaining files are (supposed to be) incompatible configurations. So I doubt anyone is using them verbatim for deployed systems. If anything they should be reference configurations not final product ones. > So I'm really asking about the issue of "how does this work during the > late -rc phase". Where the _timing_ is the important thing. Given what I said above, I think that: 1) Those files aren't critical. They're damn useful indeed, but a glitch in a defconfig file is far from being as important as a glitch in the very code they refer to. So I don't think this is all that critical if the pull is applied late in the -rc period. 2) Doing it sooner rather than later is IMHO the best thing to do. At least we could now focus on maintaining and even improving on that state rather than going on in circles wondering what to do with it. People would be able to think about how to update their defconfig files in the new form now instead of simply not updating it at all as it has been the case for a while until something happens. So to me this is all in favor for a merge before next merge window. During the merge window this would create even more headaches. > So when I ask about timing and "how does this work in late -rc", it's > really about how safe it is to do now. Because if it isn't very > obviously safe, I can't pull it. As I said above, those files aren't that critical and no one should end up in trouble if something is not exactly right after this merge. So this makes it pretty safe to me. > One part of the "obviously safe" thing is verification for each > defconfig file that the end result is identical with the reduced > version. Uwe implied that it was, and that was clearly the intention, > but was there some explicit verification that yes, the > before-and-after configurations are 100% the same? I'll let Uwe answer this. > Also, I assume that while it's _mostly_ a transparent change to users, > it does require that people do "make oldconfig" with the reduced > defconfig file first, in order to avoid having to answer with the > defaults. No? And the reduced defconfig files obviously do depend on > the default in the Kconfig files themselves, so it does have that kind > of fairly subtle semantic change that may not be entirely obvious or > easy to notice. That is going to be the case regardless of the merge timing for this. > So from a timing standpoint, I just want to be convinced that "late > -rc" really is the right thing. I'm not entirely sure it is, even > though I do see advantages. I do too. At least this is positive progress for some bad issue that no one could ever get very passionate about. Better keep the momentum. > > I think Uwe could provide his script and add it to the kernel tree. > > Then all architectures could benefit from it. ?Having the defconfig > > files contain only those options which are different from the defaults > > is certainly more readable, even on x86. > > Quite possible. But maintainers would need to be on the lookout of > people actually using the script, and refusing to apply patches that > re-introduce the whole big thing. Pretty easy to see on the diffstat graph. Anyway, I'm sure once the script is available then an army of kernel janitors will be busy trying to find any transgressor. > I also haven't actually seen the script - I don't think Uwe ever > posted it - so maybe it's some very fragile thing. Hard to judge on no > real information ;^p I'm sure the script was quickly cobbled together as a proof of concept. But once this defconfig reduction goes in then interest for a solid script should raise significantly. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 18:50 ` Uwe Kleine-König @ 2010-07-12 19:09 ` Nicolas Pitre -1 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 19:09 UTC (permalink / raw) To: Uwe Kleine-König Cc: Linus Torvalds, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap [-- Attachment #1: Type: TEXT/PLAIN, Size: 14183 bytes --] On Mon, 12 Jul 2010, Uwe Kleine-König wrote: > On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: > > I hope you at least do agree that the current situation is a steaming > > pile of sh*t. And yes, I _will_ remove the crap, both from POWER and > > ARM, unless I see some serious tries at fixing it. We all agree this is a pile of sh*t, as the truly valuable data is drawned down into it. The diffstat numbers below certainly shows it rather clearly. Linus, please pull this git tree. This should functionally be a no op, while giving us a better footing to develop a final solution. > I'm willing to try my solution, some others on the linux-arm-kernel > lists considered it worth trying, too. Feel free to pull my tree[1]. > Russell refused to take defconfig changes for a while now, so I don't > expect merge problems if you do. ACK. > If it helps the powerpc people I can reduce their defconfigs, too. > > Best regards > Uwe > > [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: > > Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) > > are available in the git repository at: > git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 > > Uwe Kleine-König (1): > ARM: reduce defconfigs > > arch/arm/configs/acs5k_defconfig | 1146 -------------- > arch/arm/configs/acs5k_tiny_defconfig | 860 ---------- > arch/arm/configs/afeb9260_defconfig | 1157 +-------------- > arch/arm/configs/am200epdkit_defconfig | 1044 +------------ > arch/arm/configs/am3517_evm_defconfig | 1250 --------------- > arch/arm/configs/ams_delta_defconfig | 1224 +-------------- > arch/arm/configs/ap4evb_defconfig | 722 --------- > arch/arm/configs/assabet_defconfig | 862 +---------- > arch/arm/configs/at572d940hfek_defconfig | 1318 +--------------- > arch/arm/configs/at91cap9adk_defconfig | 1107 +------------- > arch/arm/configs/at91rm9200dk_defconfig | 955 +----------- > arch/arm/configs/at91rm9200ek_defconfig | 942 +----------- > arch/arm/configs/at91sam9260ek_defconfig | 958 +----------- > arch/arm/configs/at91sam9261ek_defconfig | 1087 +------------- > arch/arm/configs/at91sam9263ek_defconfig | 1103 +------------- > arch/arm/configs/at91sam9g20ek_defconfig | 1049 +------------ > arch/arm/configs/at91sam9rlek_defconfig | 864 +---------- > arch/arm/configs/ateb9200_defconfig | 1222 +-------------- > arch/arm/configs/badge4_defconfig | 1178 +-------------- > arch/arm/configs/bcmring_defconfig | 721 --------- > arch/arm/configs/cam60_defconfig | 1089 +------------- > arch/arm/configs/carmeva_defconfig | 696 +-------- > arch/arm/configs/cerfcube_defconfig | 851 +---------- > arch/arm/configs/cm_t35_defconfig | 1577 +------------------ > arch/arm/configs/cm_x2xx_defconfig | 1774 +--------------------- > arch/arm/configs/cm_x300_defconfig | 1565 ------------------ > arch/arm/configs/cns3420vb_defconfig | 759 --------- > arch/arm/configs/colibri_pxa270_defconfig | 1556 ------------------ > arch/arm/configs/colibri_pxa300_defconfig | 1082 ------------- > arch/arm/configs/collie_defconfig | 887 +---------- > arch/arm/configs/corgi_defconfig | 1621 +------------------- > arch/arm/configs/cpu9260_defconfig | 1225 +-------------- > arch/arm/configs/cpu9g20_defconfig | 1215 +-------------- > arch/arm/configs/cpuat91_defconfig | 1207 +-------------- > arch/arm/configs/csb337_defconfig | 1113 +------------- > arch/arm/configs/csb637_defconfig | 1124 +------------- > arch/arm/configs/da8xx_omapl_defconfig | 1205 -------------- > arch/arm/configs/davinci_all_defconfig | 1641 ------------------- > arch/arm/configs/devkit8000_defconfig | 1732 +-------------------- > arch/arm/configs/dove_defconfig | 1482 ----------------- > arch/arm/configs/ebsa110_defconfig | 692 +-------- > arch/arm/configs/ecbat91_defconfig | 1226 +-------------- > arch/arm/configs/edb7211_defconfig | 554 +------- > arch/arm/configs/em_x270_defconfig | 1554 +------------------ > arch/arm/configs/ep93xx_defconfig | 1340 ---------------- > arch/arm/configs/eseries_pxa_defconfig | 1128 ------------- > arch/arm/configs/ezx_defconfig | 1582 +------------------- > arch/arm/configs/footbridge_defconfig | 1185 +-------------- > arch/arm/configs/fortunet_defconfig | 538 +------- > arch/arm/configs/g3evm_defconfig | 717 --------- > arch/arm/configs/g4evm_defconfig | 722 --------- > arch/arm/configs/h3600_defconfig | 1084 ------------- > arch/arm/configs/h5000_defconfig | 917 +----------- > arch/arm/configs/h7201_defconfig | 542 +------- > arch/arm/configs/h7202_defconfig | 697 +-------- > arch/arm/configs/hackkit_defconfig | 735 +--------- > arch/arm/configs/htcherald_defconfig | 1073 +------------- > arch/arm/configs/igep0020_defconfig | 1467 ----------------- > arch/arm/configs/imote2_defconfig | 1649 +------------------- > arch/arm/configs/integrator_defconfig | 817 +---------- > arch/arm/configs/iop13xx_defconfig | 1061 +------------ > arch/arm/configs/iop32x_defconfig | 1282 +--------------- > arch/arm/configs/iop33x_defconfig | 1300 --------------- > arch/arm/configs/ixp2000_defconfig | 1024 +------------ > arch/arm/configs/ixp23xx_defconfig | 1315 +--------------- > arch/arm/configs/ixp4xx_defconfig | 1394 +---------------- > arch/arm/configs/jornada720_defconfig | 1062 ------------- > arch/arm/configs/kafa_defconfig | 830 +---------- > arch/arm/configs/kb9202_defconfig | 1179 +-------------- > arch/arm/configs/kirkwood_defconfig | 1700 -------------------- > arch/arm/configs/ks8695_defconfig | 946 ----------- > arch/arm/configs/lart_defconfig | 824 +---------- > arch/arm/configs/loki_defconfig | 1028 +------------ > arch/arm/configs/lpd270_defconfig | 968 +------------ > arch/arm/configs/lpd7a400_defconfig | 835 +---------- > arch/arm/configs/lpd7a404_defconfig | 1050 +------------ > arch/arm/configs/lubbock_defconfig | 762 +--------- > arch/arm/configs/lusl7200_defconfig | 436 +----- > arch/arm/configs/magician_defconfig | 1358 +---------------- > arch/arm/configs/mainstone_defconfig | 755 +--------- > arch/arm/configs/mini2440_defconfig | 1722 +-------------------- > arch/arm/configs/mmp2_defconfig | 1135 ------------- > arch/arm/configs/msm_defconfig | 830 +---------- > arch/arm/configs/mv78xx0_defconfig | 1547 ------------------ > arch/arm/configs/mx1_defconfig | 1018 +------------ > arch/arm/configs/mx21_defconfig | 1072 ------------- > arch/arm/configs/mx27_defconfig | 1152 -------------- > arch/arm/configs/mx31pdk_defconfig | 728 --------- > arch/arm/configs/mx3_defconfig | 1089 ------------- > arch/arm/configs/mx51_defconfig | 1130 ------------- > arch/arm/configs/n770_defconfig | 1283 --------------- > arch/arm/configs/n8x0_defconfig | 1134 +------------- > arch/arm/configs/neocore926_defconfig | 1205 +-------------- > arch/arm/configs/neponset_defconfig | 1081 +------------- > arch/arm/configs/netwinder_defconfig | 978 +------------ > arch/arm/configs/netx_defconfig | 845 +---------- > arch/arm/configs/nhk8815_defconfig | 1185 +-------------- > arch/arm/configs/ns9xxx_defconfig | 23 - > arch/arm/configs/nuc910_defconfig | 844 ---------- > arch/arm/configs/nuc950_defconfig | 896 ----------- > arch/arm/configs/nuc960_defconfig | 855 ---------- > arch/arm/configs/omap3_beagle_defconfig | 1258 +--------------- > arch/arm/configs/omap3_defconfig | 1969 ----------------------- > arch/arm/configs/omap3_evm_defconfig | 1429 +----------------- > arch/arm/configs/omap3_pandora_defconfig | 1640 +------------------- > arch/arm/configs/omap3_stalker_lks_defconfig | 1541 ------------------ > arch/arm/configs/omap3_touchbook_defconfig | 1809 --------------------- > arch/arm/configs/omap_2430sdp_defconfig | 1181 +-------------- > arch/arm/configs/omap_3430sdp_defconfig | 1553 +------------------ > arch/arm/configs/omap_3630sdp_defconfig | 1456 ----------------- > arch/arm/configs/omap_4430sdp_defconfig | 1157 -------------- > arch/arm/configs/omap_apollon_2420_defconfig | 873 +---------- > arch/arm/configs/omap_generic_1510_defconfig | 1089 +------------- > arch/arm/configs/omap_generic_1610_defconfig | 1092 +------------- > arch/arm/configs/omap_generic_1710_defconfig | 1014 +------------ > arch/arm/configs/omap_generic_2420_defconfig | 619 +-------- > arch/arm/configs/omap_h2_1610_defconfig | 1234 +--------------- > arch/arm/configs/omap_h4_2420_defconfig | 1018 +------------ > arch/arm/configs/omap_innovator_1510_defconfig | 1152 +-------------- > arch/arm/configs/omap_innovator_1610_defconfig | 780 --------- > arch/arm/configs/omap_ldp_defconfig | 1124 ------------- > arch/arm/configs/omap_osk_5912_defconfig | 1003 ------------ > arch/arm/configs/omap_perseus2_730_defconfig | 862 ---------- > arch/arm/configs/omap_zoom2_defconfig | 1408 +----------------- > arch/arm/configs/omap_zoom3_defconfig | 1455 ----------------- > arch/arm/configs/onearm_defconfig | 1067 +------------- > arch/arm/configs/orion5x_defconfig | 1693 -------------------- > arch/arm/configs/overo_defconfig | 1621 +------------------- > arch/arm/configs/palmte_defconfig | 712 --------- > arch/arm/configs/palmtt_defconfig | 801 +---------- > arch/arm/configs/palmz71_defconfig | 839 +---------- > arch/arm/configs/palmz72_defconfig | 865 ---------- > arch/arm/configs/pcm027_defconfig | 993 ------------ > arch/arm/configs/picotux200_defconfig | 1207 +-------------- > arch/arm/configs/pleb_defconfig | 712 +-------- > arch/arm/configs/pnx4008_defconfig | 1286 +--------------- > arch/arm/configs/pxa168_defconfig | 903 ----------- > arch/arm/configs/pxa255-idp_defconfig | 753 +--------- > arch/arm/configs/pxa3xx_defconfig | 1207 +-------------- > arch/arm/configs/pxa910_defconfig | 820 ---------- > arch/arm/configs/qil-a9260_defconfig | 1146 +-------------- > arch/arm/configs/raumfeld_defconfig | 1690 -------------------- > arch/arm/configs/realview-smp_defconfig | 1005 ------------ > arch/arm/configs/realview_defconfig | 1001 ------------ > arch/arm/configs/rpc_defconfig | 882 +----------- > arch/arm/configs/rx51_defconfig | 1648 +------------------- > arch/arm/configs/s3c2410_defconfig | 2018 ------------------------ > arch/arm/configs/s3c6400_defconfig | 1445 ----------------- > arch/arm/configs/s5p6440_defconfig | 947 ----------- > arch/arm/configs/s5p6442_defconfig | 842 ---------- > arch/arm/configs/s5pc100_defconfig | 977 ------------ > arch/arm/configs/s5pc110_defconfig | 858 ---------- > arch/arm/configs/s5pv210_defconfig | 861 ---------- > arch/arm/configs/sam9_l9260_defconfig | 962 +----------- > arch/arm/configs/shannon_defconfig | 837 +---------- > arch/arm/configs/shark_defconfig | 1167 -------------- > arch/arm/configs/simpad_defconfig | 886 +---------- > arch/arm/configs/spear300_defconfig | 722 --------- > arch/arm/configs/spear310_defconfig | 723 --------- > arch/arm/configs/spear320_defconfig | 723 --------- > arch/arm/configs/spear600_defconfig | 711 --------- > arch/arm/configs/spitz_defconfig | 1547 +------------------ > arch/arm/configs/stamp9g20_defconfig | 1327 ---------------- > arch/arm/configs/stmp378x_defconfig | 1014 +------------ > arch/arm/configs/stmp37xx_defconfig | 895 +----------- > arch/arm/configs/sx1_defconfig | 1015 +------------ > arch/arm/configs/tct_hammer_defconfig | 817 +---------- > arch/arm/configs/trizeps4_defconfig | 1502 +----------------- > arch/arm/configs/u300_defconfig | 1118 ------------- > arch/arm/configs/u8500_defconfig | 621 -------- > arch/arm/configs/usb-a9260_defconfig | 1039 +------------ > arch/arm/configs/usb-a9263_defconfig | 1031 +------------ > arch/arm/configs/versatile_defconfig | 928 +----------- > arch/arm/configs/viper_defconfig | 1502 ------------------ > arch/arm/configs/xcep_defconfig | 1031 +------------ > arch/arm/configs/yl9200_defconfig | 1084 +------------- > arch/arm/configs/zeus_defconfig | 1842 --------------------- > 177 files changed, 652 insertions(+), 194157 deletions(-) > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | http://www.pengutronix.de/ | > ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 19:09 ` Nicolas Pitre 0 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 19:09 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, Uwe Kleine-K?nig wrote: > On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: > > I hope you at least do agree that the current situation is a steaming > > pile of sh*t. And yes, I _will_ remove the crap, both from POWER and > > ARM, unless I see some serious tries at fixing it. We all agree this is a pile of sh*t, as the truly valuable data is drawned down into it. The diffstat numbers below certainly shows it rather clearly. Linus, please pull this git tree. This should functionally be a no op, while giving us a better footing to develop a final solution. > I'm willing to try my solution, some others on the linux-arm-kernel > lists considered it worth trying, too. Feel free to pull my tree[1]. > Russell refused to take defconfig changes for a while now, so I don't > expect merge problems if you do. ACK. > If it helps the powerpc people I can reduce their defconfigs, too. > > Best regards > Uwe > > [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: > > Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) > > are available in the git repository at: > git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 > > Uwe Kleine-K?nig (1): > ARM: reduce defconfigs > > arch/arm/configs/acs5k_defconfig | 1146 -------------- > arch/arm/configs/acs5k_tiny_defconfig | 860 ---------- > arch/arm/configs/afeb9260_defconfig | 1157 +-------------- > arch/arm/configs/am200epdkit_defconfig | 1044 +------------ > arch/arm/configs/am3517_evm_defconfig | 1250 --------------- > arch/arm/configs/ams_delta_defconfig | 1224 +-------------- > arch/arm/configs/ap4evb_defconfig | 722 --------- > arch/arm/configs/assabet_defconfig | 862 +---------- > arch/arm/configs/at572d940hfek_defconfig | 1318 +--------------- > arch/arm/configs/at91cap9adk_defconfig | 1107 +------------- > arch/arm/configs/at91rm9200dk_defconfig | 955 +----------- > arch/arm/configs/at91rm9200ek_defconfig | 942 +----------- > arch/arm/configs/at91sam9260ek_defconfig | 958 +----------- > arch/arm/configs/at91sam9261ek_defconfig | 1087 +------------- > arch/arm/configs/at91sam9263ek_defconfig | 1103 +------------- > arch/arm/configs/at91sam9g20ek_defconfig | 1049 +------------ > arch/arm/configs/at91sam9rlek_defconfig | 864 +---------- > arch/arm/configs/ateb9200_defconfig | 1222 +-------------- > arch/arm/configs/badge4_defconfig | 1178 +-------------- > arch/arm/configs/bcmring_defconfig | 721 --------- > arch/arm/configs/cam60_defconfig | 1089 +------------- > arch/arm/configs/carmeva_defconfig | 696 +-------- > arch/arm/configs/cerfcube_defconfig | 851 +---------- > arch/arm/configs/cm_t35_defconfig | 1577 +------------------ > arch/arm/configs/cm_x2xx_defconfig | 1774 +--------------------- > arch/arm/configs/cm_x300_defconfig | 1565 ------------------ > arch/arm/configs/cns3420vb_defconfig | 759 --------- > arch/arm/configs/colibri_pxa270_defconfig | 1556 ------------------ > arch/arm/configs/colibri_pxa300_defconfig | 1082 ------------- > arch/arm/configs/collie_defconfig | 887 +---------- > arch/arm/configs/corgi_defconfig | 1621 +------------------- > arch/arm/configs/cpu9260_defconfig | 1225 +-------------- > arch/arm/configs/cpu9g20_defconfig | 1215 +-------------- > arch/arm/configs/cpuat91_defconfig | 1207 +-------------- > arch/arm/configs/csb337_defconfig | 1113 +------------- > arch/arm/configs/csb637_defconfig | 1124 +------------- > arch/arm/configs/da8xx_omapl_defconfig | 1205 -------------- > arch/arm/configs/davinci_all_defconfig | 1641 ------------------- > arch/arm/configs/devkit8000_defconfig | 1732 +-------------------- > arch/arm/configs/dove_defconfig | 1482 ----------------- > arch/arm/configs/ebsa110_defconfig | 692 +-------- > arch/arm/configs/ecbat91_defconfig | 1226 +-------------- > arch/arm/configs/edb7211_defconfig | 554 +------- > arch/arm/configs/em_x270_defconfig | 1554 +------------------ > arch/arm/configs/ep93xx_defconfig | 1340 ---------------- > arch/arm/configs/eseries_pxa_defconfig | 1128 ------------- > arch/arm/configs/ezx_defconfig | 1582 +------------------- > arch/arm/configs/footbridge_defconfig | 1185 +-------------- > arch/arm/configs/fortunet_defconfig | 538 +------- > arch/arm/configs/g3evm_defconfig | 717 --------- > arch/arm/configs/g4evm_defconfig | 722 --------- > arch/arm/configs/h3600_defconfig | 1084 ------------- > arch/arm/configs/h5000_defconfig | 917 +----------- > arch/arm/configs/h7201_defconfig | 542 +------- > arch/arm/configs/h7202_defconfig | 697 +-------- > arch/arm/configs/hackkit_defconfig | 735 +--------- > arch/arm/configs/htcherald_defconfig | 1073 +------------- > arch/arm/configs/igep0020_defconfig | 1467 ----------------- > arch/arm/configs/imote2_defconfig | 1649 +------------------- > arch/arm/configs/integrator_defconfig | 817 +---------- > arch/arm/configs/iop13xx_defconfig | 1061 +------------ > arch/arm/configs/iop32x_defconfig | 1282 +--------------- > arch/arm/configs/iop33x_defconfig | 1300 --------------- > arch/arm/configs/ixp2000_defconfig | 1024 +------------ > arch/arm/configs/ixp23xx_defconfig | 1315 +--------------- > arch/arm/configs/ixp4xx_defconfig | 1394 +---------------- > arch/arm/configs/jornada720_defconfig | 1062 ------------- > arch/arm/configs/kafa_defconfig | 830 +---------- > arch/arm/configs/kb9202_defconfig | 1179 +-------------- > arch/arm/configs/kirkwood_defconfig | 1700 -------------------- > arch/arm/configs/ks8695_defconfig | 946 ----------- > arch/arm/configs/lart_defconfig | 824 +---------- > arch/arm/configs/loki_defconfig | 1028 +------------ > arch/arm/configs/lpd270_defconfig | 968 +------------ > arch/arm/configs/lpd7a400_defconfig | 835 +---------- > arch/arm/configs/lpd7a404_defconfig | 1050 +------------ > arch/arm/configs/lubbock_defconfig | 762 +--------- > arch/arm/configs/lusl7200_defconfig | 436 +----- > arch/arm/configs/magician_defconfig | 1358 +---------------- > arch/arm/configs/mainstone_defconfig | 755 +--------- > arch/arm/configs/mini2440_defconfig | 1722 +-------------------- > arch/arm/configs/mmp2_defconfig | 1135 ------------- > arch/arm/configs/msm_defconfig | 830 +---------- > arch/arm/configs/mv78xx0_defconfig | 1547 ------------------ > arch/arm/configs/mx1_defconfig | 1018 +------------ > arch/arm/configs/mx21_defconfig | 1072 ------------- > arch/arm/configs/mx27_defconfig | 1152 -------------- > arch/arm/configs/mx31pdk_defconfig | 728 --------- > arch/arm/configs/mx3_defconfig | 1089 ------------- > arch/arm/configs/mx51_defconfig | 1130 ------------- > arch/arm/configs/n770_defconfig | 1283 --------------- > arch/arm/configs/n8x0_defconfig | 1134 +------------- > arch/arm/configs/neocore926_defconfig | 1205 +-------------- > arch/arm/configs/neponset_defconfig | 1081 +------------- > arch/arm/configs/netwinder_defconfig | 978 +------------ > arch/arm/configs/netx_defconfig | 845 +---------- > arch/arm/configs/nhk8815_defconfig | 1185 +-------------- > arch/arm/configs/ns9xxx_defconfig | 23 - > arch/arm/configs/nuc910_defconfig | 844 ---------- > arch/arm/configs/nuc950_defconfig | 896 ----------- > arch/arm/configs/nuc960_defconfig | 855 ---------- > arch/arm/configs/omap3_beagle_defconfig | 1258 +--------------- > arch/arm/configs/omap3_defconfig | 1969 ----------------------- > arch/arm/configs/omap3_evm_defconfig | 1429 +----------------- > arch/arm/configs/omap3_pandora_defconfig | 1640 +------------------- > arch/arm/configs/omap3_stalker_lks_defconfig | 1541 ------------------ > arch/arm/configs/omap3_touchbook_defconfig | 1809 --------------------- > arch/arm/configs/omap_2430sdp_defconfig | 1181 +-------------- > arch/arm/configs/omap_3430sdp_defconfig | 1553 +------------------ > arch/arm/configs/omap_3630sdp_defconfig | 1456 ----------------- > arch/arm/configs/omap_4430sdp_defconfig | 1157 -------------- > arch/arm/configs/omap_apollon_2420_defconfig | 873 +---------- > arch/arm/configs/omap_generic_1510_defconfig | 1089 +------------- > arch/arm/configs/omap_generic_1610_defconfig | 1092 +------------- > arch/arm/configs/omap_generic_1710_defconfig | 1014 +------------ > arch/arm/configs/omap_generic_2420_defconfig | 619 +-------- > arch/arm/configs/omap_h2_1610_defconfig | 1234 +--------------- > arch/arm/configs/omap_h4_2420_defconfig | 1018 +------------ > arch/arm/configs/omap_innovator_1510_defconfig | 1152 +-------------- > arch/arm/configs/omap_innovator_1610_defconfig | 780 --------- > arch/arm/configs/omap_ldp_defconfig | 1124 ------------- > arch/arm/configs/omap_osk_5912_defconfig | 1003 ------------ > arch/arm/configs/omap_perseus2_730_defconfig | 862 ---------- > arch/arm/configs/omap_zoom2_defconfig | 1408 +----------------- > arch/arm/configs/omap_zoom3_defconfig | 1455 ----------------- > arch/arm/configs/onearm_defconfig | 1067 +------------- > arch/arm/configs/orion5x_defconfig | 1693 -------------------- > arch/arm/configs/overo_defconfig | 1621 +------------------- > arch/arm/configs/palmte_defconfig | 712 --------- > arch/arm/configs/palmtt_defconfig | 801 +---------- > arch/arm/configs/palmz71_defconfig | 839 +---------- > arch/arm/configs/palmz72_defconfig | 865 ---------- > arch/arm/configs/pcm027_defconfig | 993 ------------ > arch/arm/configs/picotux200_defconfig | 1207 +-------------- > arch/arm/configs/pleb_defconfig | 712 +-------- > arch/arm/configs/pnx4008_defconfig | 1286 +--------------- > arch/arm/configs/pxa168_defconfig | 903 ----------- > arch/arm/configs/pxa255-idp_defconfig | 753 +--------- > arch/arm/configs/pxa3xx_defconfig | 1207 +-------------- > arch/arm/configs/pxa910_defconfig | 820 ---------- > arch/arm/configs/qil-a9260_defconfig | 1146 +-------------- > arch/arm/configs/raumfeld_defconfig | 1690 -------------------- > arch/arm/configs/realview-smp_defconfig | 1005 ------------ > arch/arm/configs/realview_defconfig | 1001 ------------ > arch/arm/configs/rpc_defconfig | 882 +----------- > arch/arm/configs/rx51_defconfig | 1648 +------------------- > arch/arm/configs/s3c2410_defconfig | 2018 ------------------------ > arch/arm/configs/s3c6400_defconfig | 1445 ----------------- > arch/arm/configs/s5p6440_defconfig | 947 ----------- > arch/arm/configs/s5p6442_defconfig | 842 ---------- > arch/arm/configs/s5pc100_defconfig | 977 ------------ > arch/arm/configs/s5pc110_defconfig | 858 ---------- > arch/arm/configs/s5pv210_defconfig | 861 ---------- > arch/arm/configs/sam9_l9260_defconfig | 962 +----------- > arch/arm/configs/shannon_defconfig | 837 +---------- > arch/arm/configs/shark_defconfig | 1167 -------------- > arch/arm/configs/simpad_defconfig | 886 +---------- > arch/arm/configs/spear300_defconfig | 722 --------- > arch/arm/configs/spear310_defconfig | 723 --------- > arch/arm/configs/spear320_defconfig | 723 --------- > arch/arm/configs/spear600_defconfig | 711 --------- > arch/arm/configs/spitz_defconfig | 1547 +------------------ > arch/arm/configs/stamp9g20_defconfig | 1327 ---------------- > arch/arm/configs/stmp378x_defconfig | 1014 +------------ > arch/arm/configs/stmp37xx_defconfig | 895 +----------- > arch/arm/configs/sx1_defconfig | 1015 +------------ > arch/arm/configs/tct_hammer_defconfig | 817 +---------- > arch/arm/configs/trizeps4_defconfig | 1502 +----------------- > arch/arm/configs/u300_defconfig | 1118 ------------- > arch/arm/configs/u8500_defconfig | 621 -------- > arch/arm/configs/usb-a9260_defconfig | 1039 +------------ > arch/arm/configs/usb-a9263_defconfig | 1031 +------------ > arch/arm/configs/versatile_defconfig | 928 +----------- > arch/arm/configs/viper_defconfig | 1502 ------------------ > arch/arm/configs/xcep_defconfig | 1031 +------------ > arch/arm/configs/yl9200_defconfig | 1084 +------------- > arch/arm/configs/zeus_defconfig | 1842 --------------------- > 177 files changed, 652 insertions(+), 194157 deletions(-) > > -- > Pengutronix e.K. | Uwe Kleine-K?nig | > Industrial Linux Solutions | http://www.pengutronix.de/ | > ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 18:50 ` Uwe Kleine-König @ 2010-07-12 20:31 ` Arnd Bergmann -1 siblings, 0 replies; 133+ messages in thread From: Arnd Bergmann @ 2010-07-12 20:31 UTC (permalink / raw) To: Uwe Kleine-König Cc: Linus Torvalds, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Monday 12 July 2010 20:50:29 Uwe Kleine-König wrote: > > [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: > > Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) > > are available in the git repository at: > git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 BTW, looking at the most common entries in there, I think we might at some point want to change some of the defaults in the respective Kconfig files. Right now an empty defconfig would result in a configuration without file system, networking or modules: sort arch/arm/configs/* | uniq -c | sort -n | tail -n 30 114 CONFIG_BLK_DEV_RAM=y 116 CONFIG_BLK_DEV_INITRD=y 116 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" 117 CONFIG_NFS_FS=y 118 CONFIG_MTD_CHAR=y 119 CONFIG_INOTIFY=y 122 # CONFIG_BLK_DEV_BSG is not set 122 CONFIG_IP_PNP=y 123 # CONFIG_IPV6 is not set 123 CONFIG_MTD_BLOCK=y 125 CONFIG_FPE_NWFPE=y 127 CONFIG_NET_ETHERNET=y 128 CONFIG_LOG_BUF_SHIFT=14 128 CONFIG_MTD=y 131 CONFIG_PACKET=y 132 # CONFIG_INPUT_MOUSE is not set 133 CONFIG_DEBUG_KERNEL=y 134 CONFIG_EXT2_FS=y 138 CONFIG_MODULE_UNLOAD=y 139 CONFIG_TMPFS=y 142 CONFIG_NETDEVICES=y 147 CONFIG_ZBOOT_ROM_BSS=0x0 147 CONFIG_ZBOOT_ROM_TEXT=0x0 151 CONFIG_INET=y 151 CONFIG_UNIX=y 153 CONFIG_NET=y 156 # CONFIG_VGA_CONSOLE is not set 158 CONFIG_MODULES=y 164 CONFIG_SYSVIPC=y 174 CONFIG_EXPERIMENTAL=y Also, some of the defconfigs contain stuff that arguably does not belong into a defconfig and could be removed in the next merge window, e.g. ezx_defconfig:CONFIG_LOCALVERSION="-ezx200910312315" pnx4008_defconfig:CONFIG_DECNET=m at572d940hfek_defconfig:CONFIG_SGI_PARTITION=y Arnd ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 20:31 ` Arnd Bergmann 0 siblings, 0 replies; 133+ messages in thread From: Arnd Bergmann @ 2010-07-12 20:31 UTC (permalink / raw) To: linux-arm-kernel On Monday 12 July 2010 20:50:29 Uwe Kleine-K?nig wrote: > > [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: > > Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) > > are available in the git repository at: > git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 BTW, looking at the most common entries in there, I think we might at some point want to change some of the defaults in the respective Kconfig files. Right now an empty defconfig would result in a configuration without file system, networking or modules: sort arch/arm/configs/* | uniq -c | sort -n | tail -n 30 114 CONFIG_BLK_DEV_RAM=y 116 CONFIG_BLK_DEV_INITRD=y 116 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" 117 CONFIG_NFS_FS=y 118 CONFIG_MTD_CHAR=y 119 CONFIG_INOTIFY=y 122 # CONFIG_BLK_DEV_BSG is not set 122 CONFIG_IP_PNP=y 123 # CONFIG_IPV6 is not set 123 CONFIG_MTD_BLOCK=y 125 CONFIG_FPE_NWFPE=y 127 CONFIG_NET_ETHERNET=y 128 CONFIG_LOG_BUF_SHIFT=14 128 CONFIG_MTD=y 131 CONFIG_PACKET=y 132 # CONFIG_INPUT_MOUSE is not set 133 CONFIG_DEBUG_KERNEL=y 134 CONFIG_EXT2_FS=y 138 CONFIG_MODULE_UNLOAD=y 139 CONFIG_TMPFS=y 142 CONFIG_NETDEVICES=y 147 CONFIG_ZBOOT_ROM_BSS=0x0 147 CONFIG_ZBOOT_ROM_TEXT=0x0 151 CONFIG_INET=y 151 CONFIG_UNIX=y 153 CONFIG_NET=y 156 # CONFIG_VGA_CONSOLE is not set 158 CONFIG_MODULES=y 164 CONFIG_SYSVIPC=y 174 CONFIG_EXPERIMENTAL=y Also, some of the defconfigs contain stuff that arguably does not belong into a defconfig and could be removed in the next merge window, e.g. ezx_defconfig:CONFIG_LOCALVERSION="-ezx200910312315" pnx4008_defconfig:CONFIG_DECNET=m at572d940hfek_defconfig:CONFIG_SGI_PARTITION=y Arnd ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 20:31 ` Arnd Bergmann (?) @ 2010-07-12 20:50 ` Nicolas Pitre -1 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 20:50 UTC (permalink / raw) To: Arnd Bergmann Cc: Uwe Kleine-König, Linus Torvalds, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap [-- Attachment #1: Type: TEXT/PLAIN, Size: 1586 bytes --] On Mon, 12 Jul 2010, Arnd Bergmann wrote: > On Monday 12 July 2010 20:50:29 Uwe Kleine-König wrote: > > > > [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: > > > > Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) > > > > are available in the git repository at: > > git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 > > BTW, looking at the most common entries in there, I think we might at some > point want to change some of the defaults in the respective Kconfig files. > Right now an empty defconfig would result in a configuration without > file system, networking or modules: We need to come up with a scheme that allows for expressing the most likely options you might want if you have machine x and/or machine y selected. Those likely options are for drivers corresponding to hardware soldered on the board or integrated into a SOC and therefore which is not "optional". Right now this information is carried in the defconfig files. Without that you need to lookup various datasheets and wade through thousands of Kconfig options. Compared to that, stuff like filesystems and networking protocols are optional items that currently are more arbitrarily included into or excluded from the defconfig files. I think that the first category of options should automatically be selected on a per machine basis depending on BASE_CONFIG or the like and expressed directly in the Kconfig files. Typically there are very few of those (like a dozen or so for some example target I looked at). Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 20:50 ` Nicolas Pitre 0 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 20:50 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, Arnd Bergmann wrote: > On Monday 12 July 2010 20:50:29 Uwe Kleine-K?nig wrote: > > > > [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: > > > > Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) > > > > are available in the git repository at: > > git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 > > BTW, looking at the most common entries in there, I think we might at some > point want to change some of the defaults in the respective Kconfig files. > Right now an empty defconfig would result in a configuration without > file system, networking or modules: We need to come up with a scheme that allows for expressing the most likely options you might want if you have machine x and/or machine y selected. Those likely options are for drivers corresponding to hardware soldered on the board or integrated into a SOC and therefore which is not "optional". Right now this information is carried in the defconfig files. Without that you need to lookup various datasheets and wade through thousands of Kconfig options. Compared to that, stuff like filesystems and networking protocols are optional items that currently are more arbitrarily included into or excluded from the defconfig files. I think that the first category of options should automatically be selected on a per machine basis depending on BASE_CONFIG or the like and expressed directly in the Kconfig files. Typically there are very few of those (like a dozen or so for some example target I looked at). Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-12 20:50 ` Nicolas Pitre 0 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 20:50 UTC (permalink / raw) To: Arnd Bergmann Cc: Daniel Walker, Russell King - ARM Linux, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, Grant Likely, linux-omap, Uwe Kleine-König, Eric Miao, Linus Torvalds, linux-arm-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 1586 bytes --] On Mon, 12 Jul 2010, Arnd Bergmann wrote: > On Monday 12 July 2010 20:50:29 Uwe Kleine-König wrote: > > > > [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: > > > > Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) > > > > are available in the git repository at: > > git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 > > BTW, looking at the most common entries in there, I think we might at some > point want to change some of the defaults in the respective Kconfig files. > Right now an empty defconfig would result in a configuration without > file system, networking or modules: We need to come up with a scheme that allows for expressing the most likely options you might want if you have machine x and/or machine y selected. Those likely options are for drivers corresponding to hardware soldered on the board or integrated into a SOC and therefore which is not "optional". Right now this information is carried in the defconfig files. Without that you need to lookup various datasheets and wade through thousands of Kconfig options. Compared to that, stuff like filesystems and networking protocols are optional items that currently are more arbitrarily included into or excluded from the defconfig files. I think that the first category of options should automatically be selected on a per machine basis depending on BASE_CONFIG or the like and expressed directly in the Kconfig files. Typically there are very few of those (like a dozen or so for some example target I looked at). Nicolas [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 18:50 ` Uwe Kleine-König @ 2010-07-12 23:05 ` David Brown -1 siblings, 0 replies; 133+ messages in thread From: David Brown @ 2010-07-12 23:05 UTC (permalink / raw) To: Uwe Kleine-König Cc: Linus Torvalds, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Monday 12 July 2010 11:50:29 Uwe Kleine-König wrote: > If it helps the powerpc people I can reduce their defconfigs, too. Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Thanks, David ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 23:05 ` David Brown 0 siblings, 0 replies; 133+ messages in thread From: David Brown @ 2010-07-12 23:05 UTC (permalink / raw) To: linux-arm-kernel On Monday 12 July 2010 11:50:29 Uwe Kleine-K?nig wrote: > If it helps the powerpc people I can reduce their defconfigs, too. Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Thanks, David ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 23:05 ` David Brown (?) @ 2010-07-12 23:18 ` Linus Torvalds -1 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 23:18 UTC (permalink / raw) To: David Brown Cc: Uwe Kleine-König, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre 2010/7/12 David Brown <davidb@codeaurora.org>: > > Do you have scripts or tools that you did this with, or is a manual > process. We're about to add several new (ARM) targets, and it'd be > nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 23:18 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 23:18 UTC (permalink / raw) To: linux-arm-kernel 2010/7/12 David Brown <davidb@codeaurora.org>: > > Do you have scripts or tools that you did this with, or is a manual > process. ?We're about to add several new (ARM) targets, and it'd be > nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-12 23:18 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 23:18 UTC (permalink / raw) To: David Brown Cc: Uwe Kleine-König, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre 2010/7/12 David Brown <davidb@codeaurora.org>: > > Do you have scripts or tools that you did this with, or is a manual > process. We're about to add several new (ARM) targets, and it'd be > nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 23:18 ` Linus Torvalds @ 2010-07-12 23:34 ` David Brown -1 siblings, 0 replies; 133+ messages in thread From: David Brown @ 2010-07-12 23:34 UTC (permalink / raw) To: Linus Torvalds Cc: Uwe Kleine-König, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: > 2010/7/12 David Brown <davidb@codeaurora.org>: > > > > Do you have scripts or tools that you did this with, or is a manual > > process. We're about to add several new (ARM) targets, and it'd be > > nice to be able to make small defconfigs for those targets as well. > > Uwe posted it earlier in this thread as an attachement, and I put the > python script into the merge commit message too. And we should > probably put it somewhere in scripts too, and/or make a 'make' target > to create the small config files. > > I pushed it all out, and tagged it as -rc5. Got it, thanks. I just pulled a bit soon. It seems a bit brute force, probably not something I can make part of our regular build process, but I can definitely run it before sending patches out. I wonder if there's a more efficient way of doing it that doesn't involve invoking make for each line of the file. It at least shouldn't be necessary to actually build the kernel each time. David ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 23:34 ` David Brown 0 siblings, 0 replies; 133+ messages in thread From: David Brown @ 2010-07-12 23:34 UTC (permalink / raw) To: linux-arm-kernel On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: > 2010/7/12 David Brown <davidb@codeaurora.org>: > > > > Do you have scripts or tools that you did this with, or is a manual > > process. We're about to add several new (ARM) targets, and it'd be > > nice to be able to make small defconfigs for those targets as well. > > Uwe posted it earlier in this thread as an attachement, and I put the > python script into the merge commit message too. And we should > probably put it somewhere in scripts too, and/or make a 'make' target > to create the small config files. > > I pushed it all out, and tagged it as -rc5. Got it, thanks. I just pulled a bit soon. It seems a bit brute force, probably not something I can make part of our regular build process, but I can definitely run it before sending patches out. I wonder if there's a more efficient way of doing it that doesn't involve invoking make for each line of the file. It at least shouldn't be necessary to actually build the kernel each time. David ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 23:34 ` David Brown @ 2010-07-13 0:55 ` Nicolas Pitre -1 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-13 0:55 UTC (permalink / raw) To: David Brown Cc: Linus Torvalds, Uwe Kleine-König, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap On Mon, 12 Jul 2010, David Brown wrote: > On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: > > > 2010/7/12 David Brown <davidb@codeaurora.org>: > > > > > > Do you have scripts or tools that you did this with, or is a manual > > > process. We're about to add several new (ARM) targets, and it'd be > > > nice to be able to make small defconfigs for those targets as well. > > > > Uwe posted it earlier in this thread as an attachement, and I put the > > python script into the merge commit message too. And we should > > probably put it somewhere in scripts too, and/or make a 'make' target > > to create the small config files. > > > > I pushed it all out, and tagged it as -rc5. > > Got it, thanks. I just pulled a bit soon. > > It seems a bit brute force, probably not something I can make part of > our regular build process, but I can definitely run it before sending > patches out. > > I wonder if there's a more efficient way of doing it that doesn't > involve invoking make for each line of the file. It at least > shouldn't be necessary to actually build the kernel each time. I'm sure that some clever people will come up with a better script eventually. Maybe this could even be generated by scripts/kconfig/conf directly. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-13 0:55 ` Nicolas Pitre 0 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-13 0:55 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, David Brown wrote: > On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: > > > 2010/7/12 David Brown <davidb@codeaurora.org>: > > > > > > Do you have scripts or tools that you did this with, or is a manual > > > process. We're about to add several new (ARM) targets, and it'd be > > > nice to be able to make small defconfigs for those targets as well. > > > > Uwe posted it earlier in this thread as an attachement, and I put the > > python script into the merge commit message too. And we should > > probably put it somewhere in scripts too, and/or make a 'make' target > > to create the small config files. > > > > I pushed it all out, and tagged it as -rc5. > > Got it, thanks. I just pulled a bit soon. > > It seems a bit brute force, probably not something I can make part of > our regular build process, but I can definitely run it before sending > patches out. > > I wonder if there's a more efficient way of doing it that doesn't > involve invoking make for each line of the file. It at least > shouldn't be necessary to actually build the kernel each time. I'm sure that some clever people will come up with a better script eventually. Maybe this could even be generated by scripts/kconfig/conf directly. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 23:34 ` David Brown @ 2010-07-14 9:13 ` Felipe Contreras -1 siblings, 0 replies; 133+ messages in thread From: Felipe Contreras @ 2010-07-14 9:13 UTC (permalink / raw) To: David Brown Cc: Linus Torvalds, Uwe Kleine-König, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Tue, Jul 13, 2010 at 2:34 AM, David Brown <davidb@codeaurora.org> wrote: > It seems a bit brute force, probably not something I can make part of > our regular build process, but I can definitely run it before sending > patches out. > > I wonder if there's a more efficient way of doing it that doesn't > involve invoking make for each line of the file. It at least > shouldn't be necessary to actually build the kernel each time. Yes, I think there's a more efficient way to do it, but it would require the SAT resolver, or something like that. -- Felipe Contreras ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-14 9:13 ` Felipe Contreras 0 siblings, 0 replies; 133+ messages in thread From: Felipe Contreras @ 2010-07-14 9:13 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 13, 2010 at 2:34 AM, David Brown <davidb@codeaurora.org> wrote: > It seems a bit brute force, probably not something I can make part of > our regular build process, but I can definitely run it before sending > patches out. > > I wonder if there's a more efficient way of doing it that doesn't > involve invoking make for each line of the file. ?It at least > shouldn't be necessary to actually build the kernel each time. Yes, I think there's a more efficient way to do it, but it would require the SAT resolver, or something like that. -- Felipe Contreras ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 23:34 ` David Brown (?) @ 2010-07-14 13:20 ` Uwe Kleine-König -1 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-14 13:20 UTC (permalink / raw) To: David Brown Cc: Linus Torvalds, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Mon, Jul 12, 2010 at 04:34:04PM -0700, David Brown wrote: > On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: > > > 2010/7/12 David Brown <davidb@codeaurora.org>: > > > > > > Do you have scripts or tools that you did this with, or is a manual > > > process. We're about to add several new (ARM) targets, and it'd be > > > nice to be able to make small defconfigs for those targets as well. > > > > Uwe posted it earlier in this thread as an attachement, and I put the > > python script into the merge commit message too. And we should > > probably put it somewhere in scripts too, and/or make a 'make' target > > to create the small config files. > > > > I pushed it all out, and tagged it as -rc5. > > Got it, thanks. I just pulled a bit soon. > > It seems a bit brute force, probably not something I can make part of > our regular build process, but I can definitely run it before sending > patches out. > > I wonder if there's a more efficient way of doing it that doesn't > involve invoking make for each line of the file. It at least > shouldn't be necessary to actually build the kernel each time. Note that no kernel is built at all, only the config is regenerated once for each line. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-14 13:20 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-14 13:20 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 04:34:04PM -0700, David Brown wrote: > On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: > > > 2010/7/12 David Brown <davidb@codeaurora.org>: > > > > > > Do you have scripts or tools that you did this with, or is a manual > > > process. We're about to add several new (ARM) targets, and it'd be > > > nice to be able to make small defconfigs for those targets as well. > > > > Uwe posted it earlier in this thread as an attachement, and I put the > > python script into the merge commit message too. And we should > > probably put it somewhere in scripts too, and/or make a 'make' target > > to create the small config files. > > > > I pushed it all out, and tagged it as -rc5. > > Got it, thanks. I just pulled a bit soon. > > It seems a bit brute force, probably not something I can make part of > our regular build process, but I can definitely run it before sending > patches out. > > I wonder if there's a more efficient way of doing it that doesn't > involve invoking make for each line of the file. It at least > shouldn't be necessary to actually build the kernel each time. Note that no kernel is built at all, only the config is regenerated once for each line. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-14 13:20 ` Uwe Kleine-König 0 siblings, 0 replies; 133+ messages in thread From: Uwe Kleine-König @ 2010-07-14 13:20 UTC (permalink / raw) To: David Brown Cc: Daniel Walker, Russell King - ARM Linux, Nicolas Pitre, Kevin Hilman, linux-arm-msm, Linux Kernel Mailing List, Grant Likely, linux-omap, Eric Miao, Linus Torvalds, linux-arm-kernel On Mon, Jul 12, 2010 at 04:34:04PM -0700, David Brown wrote: > On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: > > > 2010/7/12 David Brown <davidb@codeaurora.org>: > > > > > > Do you have scripts or tools that you did this with, or is a manual > > > process. We're about to add several new (ARM) targets, and it'd be > > > nice to be able to make small defconfigs for those targets as well. > > > > Uwe posted it earlier in this thread as an attachement, and I put the > > python script into the merge commit message too. And we should > > probably put it somewhere in scripts too, and/or make a 'make' target > > to create the small config files. > > > > I pushed it all out, and tagged it as -rc5. > > Got it, thanks. I just pulled a bit soon. > > It seems a bit brute force, probably not something I can make part of > our regular build process, but I can definitely run it before sending > patches out. > > I wonder if there's a more efficient way of doing it that doesn't > involve invoking make for each line of the file. It at least > shouldn't be necessary to actually build the kernel each time. Note that no kernel is built at all, only the config is regenerated once for each line. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-14 13:20 ` Uwe Kleine-König (?) @ 2010-07-14 17:37 ` Tony Luck -1 siblings, 0 replies; 133+ messages in thread From: Tony Luck @ 2010-07-14 17:37 UTC (permalink / raw) To: Uwe Kleine-König Cc: David Brown, Linus Torvalds, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre 2010/7/14 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: > Note that no kernel is built at all, only the config is regenerated once > for each line. You could special case blank lines and comments (other than ones like "# CONFIG_FOO is not set" which do matter). They account for ~15% of the lines in my .config files. But it probably doesn't matter all that much. I just ran reduce_defconfig in parallel on all the ia64 defconfig files (in separate build trees) and they were all done when I looked back an hour or so later. Nice tool! -Tony ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-14 17:37 ` Tony Luck 0 siblings, 0 replies; 133+ messages in thread From: Tony Luck @ 2010-07-14 17:37 UTC (permalink / raw) To: linux-arm-kernel 2010/7/14 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>: > Note that no kernel is built at all, only the config is regenerated once > for each line. You could special case blank lines and comments (other than ones like "# CONFIG_FOO is not set" which do matter). They account for ~15% of the lines in my .config files. But it probably doesn't matter all that much. I just ran reduce_defconfig in parallel on all the ia64 defconfig files (in separate build trees) and they were all done when I looked back an hour or so later. Nice tool! -Tony ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-14 17:37 ` Tony Luck 0 siblings, 0 replies; 133+ messages in thread From: Tony Luck @ 2010-07-14 17:37 UTC (permalink / raw) To: Uwe Kleine-König Cc: David Brown, Linus Torvalds, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre 2010/7/14 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: > Note that no kernel is built at all, only the config is regenerated once > for each line. You could special case blank lines and comments (other than ones like "# CONFIG_FOO is not set" which do matter). They account for ~15% of the lines in my .config files. But it probably doesn't matter all that much. I just ran reduce_defconfig in parallel on all the ia64 defconfig files (in separate build trees) and they were all done when I looked back an hour or so later. Nice tool! -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 23:18 ` Linus Torvalds @ 2010-07-13 18:32 ` Rob Landley -1 siblings, 0 replies; 133+ messages in thread From: Rob Landley @ 2010-07-13 18:32 UTC (permalink / raw) To: Linus Torvalds Cc: David Brown, Uwe Kleine-König, Russell King - ARM Linux, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre [-- Attachment #1: Type: text/plain, Size: 3690 bytes --] On Monday 12 July 2010 18:18:01 Linus Torvalds wrote: > 2010/7/12 David Brown <davidb@codeaurora.org>: > > Do you have scripts or tools that you did this with, or is a manual > > process. We're about to add several new (ARM) targets, and it'd be > > nice to be able to make small defconfigs for those targets as well. > > Uwe posted it earlier in this thread as an attachement, and I put the > python script into the merge commit message too. And we should > probably put it somewhere in scripts too, and/or make a 'make' target > to create the small config files. > > I pushed it all out, and tagged it as -rc5. FYI, I repeatedly submitted a bash script to do this back in 2005, with documentation and makefile changes to call it and so on. http://lwn.net/Articles/161086/ The current version of that script is is in my mercurial archive here: http://impactlinux.com/hg/hgwebdir.cgi/aboriginal/file/tip/sources/toys/miniconfig.sh I'm still using it in my Aboriginal Linux project. (Not just for the kernel, but for busybox and uClibc too.) Attached are miniconfigs I use for a dozen or so QEMU targets. (The project is trying to build kernels aimed at every qemu system emulation. I've got maybe 2/3 of them so far. Arm, mips, sh4, x86, x86_64, sparc...) They're used to create the system-image tarballs here: http://impactlinux.com/aboriginal/downloads/binaries/ You can download that for that target that interests you, extract it, and use run-emulator.sh to launch it under qemu. I have a cron job that does cross- platform regression testing, spitting /dev/console to a log file on the host. By the way, my build is generating those miniconfigs via a common "baseconfig" file to which I append the target-specific stuff. For example, my current baseconfig is: CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y Then for mips I append: CONFIG_MIPS_MALTA=y CONFIG_CPU_MIPS32_R2=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y #CONFIG_PM=y CONFIG_PCNET32=y CONFIG_BLK_DEV_PIIX=y Or for x86_64 it's: CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y And for armv4tl it's this big long saga (yes, with comments): # Processor config # QEMU patch: http://www.mail-archive.com/qemu-devel@nongnu.org/msg19370.html # and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the # processor that actually _needs_ this code. But until then, qemu can only # emulate an armv5 CPU... CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_VFP=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y Rob -- GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem Forever, and as welcome as New Coke. [-- Attachment #2: miniconfig-armv4eb --] [-- Type: text/plain, Size: 999 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_ARCH_VERSATILE_PB=y CONFIG_MACH_VERSATILE_AB=y CONFIG_CPU_ARM926T=y CONFIG_ARM_THUMB=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y [-- Attachment #3: miniconfig-armv4l --] [-- Type: text/plain, Size: 1381 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y # Processor config # QEMU patch: http://www.mail-archive.com/qemu-devel@nongnu.org/msg19370.html # and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the # processor that actually _needs_ this code. But until then, qemu can only # emulate an armv5 CPU... CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y [-- Attachment #4: miniconfig-armv4tl --] [-- Type: text/plain, Size: 1394 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y # Processor config # QEMU patch: http://www.mail-archive.com/qemu-devel@nongnu.org/msg19370.html # and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the # processor that actually _needs_ this code. But until then, qemu can only # emulate an armv5 CPU... CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_VFP=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y [-- Attachment #5: miniconfig-armv5l --] [-- Type: text/plain, Size: 1139 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y # Processor config CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_VFP=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y [-- Attachment #6: miniconfig-armv6l --] [-- Type: text/plain, Size: 1134 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y # Processor config CONFIG_CPU_V6=y CONFIG_MMU=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y CONFIG_VFP=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y [-- Attachment #7: miniconfig-i486 --] [-- Type: text/plain, Size: 894 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_M486=y CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y [-- Attachment #8: miniconfig-i586 --] [-- Type: text/plain, Size: 894 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_M586=y CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y [-- Attachment #9: miniconfig-i686 --] [-- Type: text/plain, Size: 900 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_MPENTIUMII=y CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y [-- Attachment #10: miniconfig-mips --] [-- Type: text/plain, Size: 903 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_MIPS_MALTA=y CONFIG_CPU_MIPS32_R2=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y #CONFIG_PM=y CONFIG_PCNET32=y CONFIG_BLK_DEV_PIIX=y [-- Attachment #11: miniconfig-mips64 --] [-- Type: text/plain, Size: 905 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_CPU_MIPS64_R1=y CONFIG_64BIT=y CONFIG_MIPS_MALTA=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_PCNET32=y CONFIG_BLK_DEV_PIIX=y [-- Attachment #12: miniconfig-mipsel --] [-- Type: text/plain, Size: 917 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_MIPS_MALTA=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_CPU_MIPS32_R2=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_PCNET32=y CONFIG_BLK_DEV_PIIX=y [-- Attachment #13: miniconfig-powerpc --] [-- Type: text/plain, Size: 1711 bytes --] CONFIG_ALTIVEC=y CONFIG_EXPERIMENTAL=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BLK_DEV_INITRD=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y CONFIG_LBDAF=y CONFIG_PPC_PMAC=y CONFIG_PPC_OF_BOOT_TRAMPOLINE=y CONFIG_PPC601_SYNC_FIX=y CONFIG_HIGHMEM=y CONFIG_NO_HZ=y CONFIG_BINFMT_ELF=y CONFIG_PROC_DEVICETREE=y CONFIG_PM=y CONFIG_SECCOMP=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_YENTA=y CONFIG_ADVANCED_OPTIONS=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_INET_LRO=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_PROC_FS=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_IDE_PMAC=y CONFIG_IEEE1394=y CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_ETH1394=y CONFIG_IEEE1394_RAWIO=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_DV1394=y CONFIG_MACINTOSH_DRIVERS=y CONFIG_ADB=y CONFIG_ADB_CUDA=y CONFIG_ADB_PMU=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_MACE=y CONFIG_BMAC=y CONFIG_HAPPYMEAL=y CONFIG_SUNGEM=y CONFIG_CASSINI=y CONFIG_NET_PCI=y CONFIG_PCNET32=y CONFIG_NE2K_PCI=y CONFIG_8139CP=y CONFIG_8139TOO=y CONFIG_8139TOO_PIO=y CONFIG_SERIO=y CONFIG_SERIAL_PMACZILOG=y CONFIG_SERIAL_PMACZILOG_TTYS=y CONFIG_SERIAL_PMACZILOG_CONSOLE=y CONFIG_HW_RANDOM=y CONFIG_SSB=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_PCMCIAHOST=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_LIBCRC32C=y CONFIG_BOOTX_TEXT=y CONFIG_CRYPTO_HW=y [-- Attachment #14: miniconfig-powerpc-440fp --] [-- Type: text/plain, Size: 1711 bytes --] CONFIG_ALTIVEC=y CONFIG_EXPERIMENTAL=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BLK_DEV_INITRD=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y CONFIG_LBDAF=y CONFIG_PPC_PMAC=y CONFIG_PPC_OF_BOOT_TRAMPOLINE=y CONFIG_PPC601_SYNC_FIX=y CONFIG_HIGHMEM=y CONFIG_NO_HZ=y CONFIG_BINFMT_ELF=y CONFIG_PROC_DEVICETREE=y CONFIG_PM=y CONFIG_SECCOMP=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_YENTA=y CONFIG_ADVANCED_OPTIONS=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_INET_LRO=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_PROC_FS=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_IDE_PMAC=y CONFIG_IEEE1394=y CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_ETH1394=y CONFIG_IEEE1394_RAWIO=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_DV1394=y CONFIG_MACINTOSH_DRIVERS=y CONFIG_ADB=y CONFIG_ADB_CUDA=y CONFIG_ADB_PMU=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_MACE=y CONFIG_BMAC=y CONFIG_HAPPYMEAL=y CONFIG_SUNGEM=y CONFIG_CASSINI=y CONFIG_NET_PCI=y CONFIG_PCNET32=y CONFIG_NE2K_PCI=y CONFIG_8139CP=y CONFIG_8139TOO=y CONFIG_8139TOO_PIO=y CONFIG_SERIO=y CONFIG_SERIAL_PMACZILOG=y CONFIG_SERIAL_PMACZILOG_TTYS=y CONFIG_SERIAL_PMACZILOG_CONSOLE=y CONFIG_HW_RANDOM=y CONFIG_SSB=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_PCMCIAHOST=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_LIBCRC32C=y CONFIG_BOOTX_TEXT=y CONFIG_CRYPTO_HW=y [-- Attachment #15: miniconfig-sh4 --] [-- Type: text/plain, Size: 3216 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_UID16=y CONFIG_KALLSYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y CONFIG_PROFILING=y CONFIG_OPROFILE=y CONFIG_BLOCK=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y CONFIG_CPU_SUBTYPE_SH7751R=y CONFIG_MMU=y CONFIG_MEMORY_START=0x0c000000 CONFIG_VSYSCALL=y CONFIG_FLATMEM_MANUAL=y CONFIG_SH_FPU=y CONFIG_SH_RTS7751R2D=y CONFIG_RTS7751R2D_PLUS=y CONFIG_SH_TIMER_TMU=y CONFIG_NO_HZ=y CONFIG_HEARTBEAT=y CONFIG_PCI=y CONFIG_SH_PCIDMA_NONCOHERENT=y CONFIG_PCI_LEGACY=y CONFIG_HOTPLUG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_XFRM_MODE_BEET=y CONFIG_INET_DIAG=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_RAM=y CONFIG_MISC_DEVICES=y CONFIG_SCSI_PROC_FS=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_LOWLEVEL=y CONFIG_ATA=y CONFIG_SATA_PMP=y CONFIG_ATA_SFF=y CONFIG_PATA_PLATFORM=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_8139TOO=y CONFIG_NETDEV_1000=y CONFIG_NETDEV_10000=y CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_DEVKMEM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_SH_SCI=y CONFIG_SERIAL_SH_SCI_NR_UARTS=1 CONFIG_SERIAL_SH_SCI_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_HW_RANDOM=y CONFIG_SPI=y CONFIG_SPI_SH_SCI=y CONFIG_HWMON=y CONFIG_MFD_SM501=y CONFIG_FB=y CONFIG_FB_SM501=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_LOGO=y CONFIG_LOGO_SUPERH_CLUT224=y CONFIG_SOUND=y CONFIG_HID_SUPPORT=y CONFIG_USB_HID=y CONFIG_HID_A4TECH=y CONFIG_HID_APPLE=y CONFIG_HID_BELKIN=y CONFIG_HID_CHERRY=y CONFIG_HID_CHICONY=y CONFIG_HID_CYPRESS=y CONFIG_HID_EZKEY=y CONFIG_HID_GYRATION=y CONFIG_HID_LOGITECH=y CONFIG_HID_MICROSOFT=y CONFIG_HID_MONTEREY=y CONFIG_HID_PANTHERLORD=y CONFIG_HID_PETALYNX=y CONFIG_HID_SAMSUNG=y CONFIG_HID_SONY=y CONFIG_HID_SUNPLUS=y CONFIG_USB_SUPPORT=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_DEVICE_CLASS=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_STORAGE=y CONFIG_USB_LIBUSUAL=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_DRV_R9701=y CONFIG_EXT2_FS=y CONFIG_FILE_LOCKING=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MINIX_FS=y CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NLS_CODEPAGE_932=y CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_EARLY_SCIF_CONSOLE=y CONFIG_EARLY_PRINTK=y CONFIG_CRYPTO_HW=y CONFIG_CRC_T10DIF=y [-- Attachment #16: miniconfig-sparc --] [-- Type: text/plain, Size: 879 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_SCSI_SUNESP=y CONFIG_SUNLANCE=y CONFIG_SERIAL_SUNZILOG=y CONFIG_SERIAL_SUNZILOG_CONSOLE=y CONFIG_SUN_MOSTEK_RTC=y [-- Attachment #17: miniconfig-x86_64 --] [-- Type: text/plain, Size: 880 bytes --] CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-13 18:32 ` Rob Landley 0 siblings, 0 replies; 133+ messages in thread From: Rob Landley @ 2010-07-13 18:32 UTC (permalink / raw) To: linux-arm-kernel On Monday 12 July 2010 18:18:01 Linus Torvalds wrote: > 2010/7/12 David Brown <davidb@codeaurora.org>: > > Do you have scripts or tools that you did this with, or is a manual > > process. We're about to add several new (ARM) targets, and it'd be > > nice to be able to make small defconfigs for those targets as well. > > Uwe posted it earlier in this thread as an attachement, and I put the > python script into the merge commit message too. And we should > probably put it somewhere in scripts too, and/or make a 'make' target > to create the small config files. > > I pushed it all out, and tagged it as -rc5. FYI, I repeatedly submitted a bash script to do this back in 2005, with documentation and makefile changes to call it and so on. http://lwn.net/Articles/161086/ The current version of that script is is in my mercurial archive here: http://impactlinux.com/hg/hgwebdir.cgi/aboriginal/file/tip/sources/toys/miniconfig.sh I'm still using it in my Aboriginal Linux project. (Not just for the kernel, but for busybox and uClibc too.) Attached are miniconfigs I use for a dozen or so QEMU targets. (The project is trying to build kernels aimed at every qemu system emulation. I've got maybe 2/3 of them so far. Arm, mips, sh4, x86, x86_64, sparc...) They're used to create the system-image tarballs here: http://impactlinux.com/aboriginal/downloads/binaries/ You can download that for that target that interests you, extract it, and use run-emulator.sh to launch it under qemu. I have a cron job that does cross- platform regression testing, spitting /dev/console to a log file on the host. By the way, my build is generating those miniconfigs via a common "baseconfig" file to which I append the target-specific stuff. For example, my current baseconfig is: CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y Then for mips I append: CONFIG_MIPS_MALTA=y CONFIG_CPU_MIPS32_R2=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y #CONFIG_PM=y CONFIG_PCNET32=y CONFIG_BLK_DEV_PIIX=y Or for x86_64 it's: CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y And for armv4tl it's this big long saga (yes, with comments): # Processor config # QEMU patch: http://www.mail-archive.com/qemu-devel at nongnu.org/msg19370.html # and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the # processor that actually _needs_ this code. But until then, qemu can only # emulate an armv5 CPU... CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_VFP=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y Rob -- GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem Forever, and as welcome as New Coke. -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_ARCH_VERSATILE_PB=y CONFIG_MACH_VERSATILE_AB=y CONFIG_CPU_ARM926T=y CONFIG_ARM_THUMB=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y # Processor config # QEMU patch: http://www.mail-archive.com/qemu-devel at nongnu.org/msg19370.html # and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the # processor that actually _needs_ this code. But until then, qemu can only # emulate an armv5 CPU... CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y # Processor config # QEMU patch: http://www.mail-archive.com/qemu-devel at nongnu.org/msg19370.html # and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the # processor that actually _needs_ this code. But until then, qemu can only # emulate an armv5 CPU... CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_VFP=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y # Processor config CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_VFP=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y # Processor config CONFIG_CPU_V6=y CONFIG_MMU=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y CONFIG_VFP=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_M486=y CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_M586=y CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_MPENTIUMII=y CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_MIPS_MALTA=y CONFIG_CPU_MIPS32_R2=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y #CONFIG_PM=y CONFIG_PCNET32=y CONFIG_BLK_DEV_PIIX=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_CPU_MIPS64_R1=y CONFIG_64BIT=y CONFIG_MIPS_MALTA=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_PCNET32=y CONFIG_BLK_DEV_PIIX=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_MIPS_MALTA=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_CPU_MIPS32_R2=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_PCNET32=y CONFIG_BLK_DEV_PIIX=y -------------- next part -------------- CONFIG_ALTIVEC=y CONFIG_EXPERIMENTAL=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BLK_DEV_INITRD=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y CONFIG_LBDAF=y CONFIG_PPC_PMAC=y CONFIG_PPC_OF_BOOT_TRAMPOLINE=y CONFIG_PPC601_SYNC_FIX=y CONFIG_HIGHMEM=y CONFIG_NO_HZ=y CONFIG_BINFMT_ELF=y CONFIG_PROC_DEVICETREE=y CONFIG_PM=y CONFIG_SECCOMP=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_YENTA=y CONFIG_ADVANCED_OPTIONS=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_INET_LRO=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_PROC_FS=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_IDE_PMAC=y CONFIG_IEEE1394=y CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_ETH1394=y CONFIG_IEEE1394_RAWIO=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_DV1394=y CONFIG_MACINTOSH_DRIVERS=y CONFIG_ADB=y CONFIG_ADB_CUDA=y CONFIG_ADB_PMU=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_MACE=y CONFIG_BMAC=y CONFIG_HAPPYMEAL=y CONFIG_SUNGEM=y CONFIG_CASSINI=y CONFIG_NET_PCI=y CONFIG_PCNET32=y CONFIG_NE2K_PCI=y CONFIG_8139CP=y CONFIG_8139TOO=y CONFIG_8139TOO_PIO=y CONFIG_SERIO=y CONFIG_SERIAL_PMACZILOG=y CONFIG_SERIAL_PMACZILOG_TTYS=y CONFIG_SERIAL_PMACZILOG_CONSOLE=y CONFIG_HW_RANDOM=y CONFIG_SSB=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_PCMCIAHOST=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_LIBCRC32C=y CONFIG_BOOTX_TEXT=y CONFIG_CRYPTO_HW=y -------------- next part -------------- CONFIG_ALTIVEC=y CONFIG_EXPERIMENTAL=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BLK_DEV_INITRD=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y CONFIG_LBDAF=y CONFIG_PPC_PMAC=y CONFIG_PPC_OF_BOOT_TRAMPOLINE=y CONFIG_PPC601_SYNC_FIX=y CONFIG_HIGHMEM=y CONFIG_NO_HZ=y CONFIG_BINFMT_ELF=y CONFIG_PROC_DEVICETREE=y CONFIG_PM=y CONFIG_SECCOMP=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_YENTA=y CONFIG_ADVANCED_OPTIONS=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_INET_LRO=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_PROC_FS=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_IDE_PMAC=y CONFIG_IEEE1394=y CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_ETH1394=y CONFIG_IEEE1394_RAWIO=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_DV1394=y CONFIG_MACINTOSH_DRIVERS=y CONFIG_ADB=y CONFIG_ADB_CUDA=y CONFIG_ADB_PMU=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_MACE=y CONFIG_BMAC=y CONFIG_HAPPYMEAL=y CONFIG_SUNGEM=y CONFIG_CASSINI=y CONFIG_NET_PCI=y CONFIG_PCNET32=y CONFIG_NE2K_PCI=y CONFIG_8139CP=y CONFIG_8139TOO=y CONFIG_8139TOO_PIO=y CONFIG_SERIO=y CONFIG_SERIAL_PMACZILOG=y CONFIG_SERIAL_PMACZILOG_TTYS=y CONFIG_SERIAL_PMACZILOG_CONSOLE=y CONFIG_HW_RANDOM=y CONFIG_SSB=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_PCMCIAHOST=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_LIBCRC32C=y CONFIG_BOOTX_TEXT=y CONFIG_CRYPTO_HW=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_UID16=y CONFIG_KALLSYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y CONFIG_PROFILING=y CONFIG_OPROFILE=y CONFIG_BLOCK=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y CONFIG_CPU_SUBTYPE_SH7751R=y CONFIG_MMU=y CONFIG_MEMORY_START=0x0c000000 CONFIG_VSYSCALL=y CONFIG_FLATMEM_MANUAL=y CONFIG_SH_FPU=y CONFIG_SH_RTS7751R2D=y CONFIG_RTS7751R2D_PLUS=y CONFIG_SH_TIMER_TMU=y CONFIG_NO_HZ=y CONFIG_HEARTBEAT=y CONFIG_PCI=y CONFIG_SH_PCIDMA_NONCOHERENT=y CONFIG_PCI_LEGACY=y CONFIG_HOTPLUG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_XFRM_MODE_BEET=y CONFIG_INET_DIAG=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_RAM=y CONFIG_MISC_DEVICES=y CONFIG_SCSI_PROC_FS=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_LOWLEVEL=y CONFIG_ATA=y CONFIG_SATA_PMP=y CONFIG_ATA_SFF=y CONFIG_PATA_PLATFORM=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_8139TOO=y CONFIG_NETDEV_1000=y CONFIG_NETDEV_10000=y CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_DEVKMEM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_SH_SCI=y CONFIG_SERIAL_SH_SCI_NR_UARTS=1 CONFIG_SERIAL_SH_SCI_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_HW_RANDOM=y CONFIG_SPI=y CONFIG_SPI_SH_SCI=y CONFIG_HWMON=y CONFIG_MFD_SM501=y CONFIG_FB=y CONFIG_FB_SM501=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_LOGO=y CONFIG_LOGO_SUPERH_CLUT224=y CONFIG_SOUND=y CONFIG_HID_SUPPORT=y CONFIG_USB_HID=y CONFIG_HID_A4TECH=y CONFIG_HID_APPLE=y CONFIG_HID_BELKIN=y CONFIG_HID_CHERRY=y CONFIG_HID_CHICONY=y CONFIG_HID_CYPRESS=y CONFIG_HID_EZKEY=y CONFIG_HID_GYRATION=y CONFIG_HID_LOGITECH=y CONFIG_HID_MICROSOFT=y CONFIG_HID_MONTEREY=y CONFIG_HID_PANTHERLORD=y CONFIG_HID_PETALYNX=y CONFIG_HID_SAMSUNG=y CONFIG_HID_SONY=y CONFIG_HID_SUNPLUS=y CONFIG_USB_SUPPORT=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_DEVICE_CLASS=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_STORAGE=y CONFIG_USB_LIBUSUAL=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_DRV_R9701=y CONFIG_EXT2_FS=y CONFIG_FILE_LOCKING=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MINIX_FS=y CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NLS_CODEPAGE_932=y CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_EARLY_SCIF_CONSOLE=y CONFIG_EARLY_PRINTK=y CONFIG_CRYPTO_HW=y CONFIG_CRC_T10DIF=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_SCSI_SUNESP=y CONFIG_SUNLANCE=y CONFIG_SERIAL_SUNZILOG=y CONFIG_SERIAL_SUNZILOG_CONSOLE=y CONFIG_SUN_MOSTEK_RTC=y -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 17:40 ` Linus Torvalds @ 2010-07-12 20:06 ` Russell King - ARM Linux -1 siblings, 0 replies; 133+ messages in thread From: Russell King - ARM Linux @ 2010-07-12 20:06 UTC (permalink / raw) To: Linus Torvalds Cc: Uwe Kleine-König, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > > When you brought up the problem you seemed absolutely convinced > > that nothing except your solution was going to be acceptable. > > That's not true. What's true is that you didn't seem to _understand_ > my solution, so I tried to push the understanding of it. That's your point of view. My viewpoint was that I had read your email, thought of some alternative solution, proposed it and the result was shot down without any apparant thought about it. That gave the impression that you _only_ wanted to see your own solution. The result of that has been very little in the way of progress towards either your, or my alternative solutions - and apart from a few Kconfig corner quirk patches, the only major work that's happened has been from Uwe. So in that regard, I support Uwe's patches as a means to prevent the impending loss of build coverage from facilities such as linux-next and the ARM kernel autobuilder, as that's the only option that's currently available. As far as timing goes, I see no reason for it to be merged during -rc. As has already been said, I'm intending _not_ to make the defconfig situation any worse by accepting patches which add to the mess, as I'm also mindful that its exactly those kinds of patches are the cause of this problem. Now, I'm happy to take Uwe's tree through mine for the next merge window _iff_ you find his solution acceptable, and you want that to happen. I'll also use this opportunity to warn you now - especially as you also complained about the amount of churn. There is an effort to try to allow a single ARM kernel to boot on a wider range of platforms with more differences than it currently does. This is going to mean a certain amount of restructuring, and a lot of additional patches over time to gradually convert the code. So, I'm expecting that there will be even _more_ patches - some fairly big - to come over the next year or so. To give an idea - if we change the structure which defines a machine's properties, we're going to be changing 348 files under arch/arm to match. Clearly that's also going to give you a problem with diffstat being swamped. ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 20:06 ` Russell King - ARM Linux 0 siblings, 0 replies; 133+ messages in thread From: Russell King - ARM Linux @ 2010-07-12 20:06 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > > When you brought up the problem you seemed absolutely convinced > > that nothing except your solution was going to be acceptable. > > That's not true. What's true is that you didn't seem to _understand_ > my solution, so I tried to push the understanding of it. That's your point of view. My viewpoint was that I had read your email, thought of some alternative solution, proposed it and the result was shot down without any apparant thought about it. That gave the impression that you _only_ wanted to see your own solution. The result of that has been very little in the way of progress towards either your, or my alternative solutions - and apart from a few Kconfig corner quirk patches, the only major work that's happened has been from Uwe. So in that regard, I support Uwe's patches as a means to prevent the impending loss of build coverage from facilities such as linux-next and the ARM kernel autobuilder, as that's the only option that's currently available. As far as timing goes, I see no reason for it to be merged during -rc. As has already been said, I'm intending _not_ to make the defconfig situation any worse by accepting patches which add to the mess, as I'm also mindful that its exactly those kinds of patches are the cause of this problem. Now, I'm happy to take Uwe's tree through mine for the next merge window _iff_ you find his solution acceptable, and you want that to happen. I'll also use this opportunity to warn you now - especially as you also complained about the amount of churn. There is an effort to try to allow a single ARM kernel to boot on a wider range of platforms with more differences than it currently does. This is going to mean a certain amount of restructuring, and a lot of additional patches over time to gradually convert the code. So, I'm expecting that there will be even _more_ patches - some fairly big - to come over the next year or so. To give an idea - if we change the structure which defines a machine's properties, we're going to be changing 348 files under arch/arm to match. Clearly that's also going to give you a problem with diffstat being swamped. ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 20:06 ` Russell King - ARM Linux @ 2010-07-12 20:29 ` Nicolas Pitre -1 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 20:29 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Linus Torvalds, Uwe Kleine-König, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap On Mon, 12 Jul 2010, Russell King - ARM Linux wrote: > On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: > > On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux > > <linux@arm.linux.org.uk> wrote: > > > > > > When you brought up the problem you seemed absolutely convinced > > > that nothing except your solution was going to be acceptable. > > > > That's not true. What's true is that you didn't seem to _understand_ > > my solution, so I tried to push the understanding of it. > > That's your point of view. > > My viewpoint was that I had read your email, thought of some alternative > solution, proposed it and the result was shot down without any apparant > thought about it. That gave the impression that you _only_ wanted to > see your own solution. OK, please let's put this appearance of misunderstanding behind. The rehashing of it from either parties doesn't produce any good. > The result of that has been very little in the way of progress towards > either your, or my alternative solutions - and apart from a few Kconfig > corner quirk patches, the only major work that's happened has been from > Uwe. For the record, I do support Uwe's work too. I do wish it could go in now so that from that point going forward we could only focus on improving the thing instead of having to care about implications during the merge window. But I do prefer RMK's proposal in the long run. Not only is it more expressive and clear, but it is easier to maintain going forward too. But that transition cannot be automated and I doubt the majority of targets will be converted anytime soon if at all. So at least Uwe's reduction is quite a good compromise for those. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 20:29 ` Nicolas Pitre 0 siblings, 0 replies; 133+ messages in thread From: Nicolas Pitre @ 2010-07-12 20:29 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, Russell King - ARM Linux wrote: > On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: > > On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux > > <linux@arm.linux.org.uk> wrote: > > > > > > When you brought up the problem you seemed absolutely convinced > > > that nothing except your solution was going to be acceptable. > > > > That's not true. What's true is that you didn't seem to _understand_ > > my solution, so I tried to push the understanding of it. > > That's your point of view. > > My viewpoint was that I had read your email, thought of some alternative > solution, proposed it and the result was shot down without any apparant > thought about it. That gave the impression that you _only_ wanted to > see your own solution. OK, please let's put this appearance of misunderstanding behind. The rehashing of it from either parties doesn't produce any good. > The result of that has been very little in the way of progress towards > either your, or my alternative solutions - and apart from a few Kconfig > corner quirk patches, the only major work that's happened has been from > Uwe. For the record, I do support Uwe's work too. I do wish it could go in now so that from that point going forward we could only focus on improving the thing instead of having to care about implications during the merge window. But I do prefer RMK's proposal in the long run. Not only is it more expressive and clear, but it is easier to maintain going forward too. But that transition cannot be automated and I doubt the majority of targets will be converted anytime soon if at all. So at least Uwe's reduction is quite a good compromise for those. Nicolas ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 20:29 ` Nicolas Pitre @ 2010-07-12 21:54 ` Linus Torvalds -1 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 21:54 UTC (permalink / raw) To: Nicolas Pitre Cc: Russell King - ARM Linux, Uwe Kleine-König, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap On Mon, Jul 12, 2010 at 1:29 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > For the record, I do support Uwe's work too. I do wish it could go in > now so that from that point going forward we could only focus on > improving the thing instead of having to care about implications during > the merge window. Ok, I merged it. I do love the diffstat. And while it may not be optimal or a final solution, nobody seems to hate it either. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-12 21:54 ` Linus Torvalds 0 siblings, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-07-12 21:54 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 1:29 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > For the record, I do support Uwe's work too. ?I do wish it could go in > now so that from that point going forward we could only focus on > improving the thing instead of having to care about implications during > the merge window. Ok, I merged it. I do love the diffstat. And while it may not be optimal or a final solution, nobody seems to hate it either. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-07-12 20:06 ` Russell King - ARM Linux (?) @ 2010-07-14 9:21 ` Felipe Contreras -1 siblings, 0 replies; 133+ messages in thread From: Felipe Contreras @ 2010-07-14 9:21 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Linus Torvalds, Uwe Kleine-König, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Mon, Jul 12, 2010 at 11:06 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: >> On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > >> > When you brought up the problem you seemed absolutely convinced >> > that nothing except your solution was going to be acceptable. >> >> That's not true. What's true is that you didn't seem to _understand_ >> my solution, so I tried to push the understanding of it. > > That's your point of view. > > My viewpoint was that I had read your email, thought of some alternative > solution, proposed it and the result was shot down without any apparant > thought about it. That gave the impression that you _only_ wanted to > see your own solution. I think you got it wrong. Linus liked my proposal of minimal defconfigs, and the only discrepancy was on the format: http://article.gmane.org/gmane.linux.kernel/995419 -- Felipe Contreras ^ permalink raw reply [flat|nested] 133+ messages in thread
* ARM defconfig files @ 2010-07-14 9:21 ` Felipe Contreras 0 siblings, 0 replies; 133+ messages in thread From: Felipe Contreras @ 2010-07-14 9:21 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 11:06 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: >> On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > >> > When you brought up the problem you seemed absolutely convinced >> > that nothing except your solution was going to be acceptable. >> >> That's not true. What's true is that you didn't seem to _understand_ >> my solution, so I tried to push the understanding of it. > > That's your point of view. > > My viewpoint was that I had read your email, thought of some alternative > solution, proposed it and the result was shot down without any apparant > thought about it. ?That gave the impression that you _only_ wanted to > see your own solution. I think you got it wrong. Linus liked my proposal of minimal defconfigs, and the only discrepancy was on the format: http://article.gmane.org/gmane.linux.kernel/995419 -- Felipe Contreras ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files @ 2010-07-14 9:21 ` Felipe Contreras 0 siblings, 0 replies; 133+ messages in thread From: Felipe Contreras @ 2010-07-14 9:21 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Linus Torvalds, Uwe Kleine-König, Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm, linux-arm-kernel, Grant Likely, Eric Miao, linux-omap, Nicolas Pitre On Mon, Jul 12, 2010 at 11:06 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: >> On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > >> > When you brought up the problem you seemed absolutely convinced >> > that nothing except your solution was going to be acceptable. >> >> That's not true. What's true is that you didn't seem to _understand_ >> my solution, so I tried to push the understanding of it. > > That's your point of view. > > My viewpoint was that I had read your email, thought of some alternative > solution, proposed it and the result was shot down without any apparant > thought about it. That gave the impression that you _only_ wanted to > see your own solution. I think you got it wrong. Linus liked my proposal of minimal defconfigs, and the only discrepancy was on the format: http://article.gmane.org/gmane.linux.kernel/995419 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:20 ` Daniel Walker 2010-06-03 18:21 ` Linus Torvalds @ 2010-06-03 18:41 ` Russell King 2010-06-03 18:53 ` Linus Torvalds 2010-06-06 3:53 ` david 1 sibling, 2 replies; 133+ messages in thread From: Russell King @ 2010-06-03 18:41 UTC (permalink / raw) To: Daniel Walker Cc: Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, Jun 03, 2010 at 11:20:30AM -0700, Daniel Walker wrote: > I don't see how we can do without defconfigs altogether tho. I mean , if > you want to run a Beagle board or a Nexus one we can't just give the > users a slim ARM config and let them troll through 1000's of drivers > trying to find just those ones that work on their given board. Well, Linus does have a point - I can't start a new with Kconfig and generate a working defconfig first time mainly because of the thounds of options there. What I can do is get the ARM side of the configuration right, since for the majority of cases the only thing that needs doing is selecting the platform class and the board itself. The problem comes with driver configuration, where you have to go through lots of menus to find all the drivers for the platform/SoC. That's the tedious bit, and more often than not it takes several attempts to get everything that's necessary. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:41 ` Russell King @ 2010-06-03 18:53 ` Linus Torvalds 2010-06-06 3:53 ` david 1 sibling, 0 replies; 133+ messages in thread From: Linus Torvalds @ 2010-06-03 18:53 UTC (permalink / raw) To: Russell King Cc: Daniel Walker, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Russell King wrote: > > The problem comes with driver configuration, where you have to go > through lots of menus to find all the drivers for the platform/SoC. > That's the tedious bit, and more often than not it takes several > attempts to get everything that's necessary. It's often tedious for other cases too ("I just want to enable a particular driver, what do I need to do so?"), and I do agree with Daniel that the SAT solver approach sounds interesting as a way to solve some of the complexities. At the same time, "SAT solver" does scream "over-engineering failure" to me. We've had horribly bad experiences with over-engineering in that space before. Yes, I know about MiniSAT and that these things can be done without necessarily huge amounts of complex code, but these things tend to grow to huge monsters. Who knows. Linus ^ permalink raw reply [flat|nested] 133+ messages in thread
* Re: ARM defconfig files 2010-06-03 18:41 ` Russell King 2010-06-03 18:53 ` Linus Torvalds @ 2010-06-06 3:53 ` david 1 sibling, 0 replies; 133+ messages in thread From: david @ 2010-06-06 3:53 UTC (permalink / raw) To: Russell King Cc: Daniel Walker, Linus Torvalds, Kevin Hilman, Linux Kernel Mailing List, linux-arm-msm On Thu, 3 Jun 2010, Russell King wrote: > On Thu, Jun 03, 2010 at 11:20:30AM -0700, Daniel Walker wrote: >> I don't see how we can do without defconfigs altogether tho. I mean , if >> you want to run a Beagle board or a Nexus one we can't just give the >> users a slim ARM config and let them troll through 1000's of drivers >> trying to find just those ones that work on their given board. > > Well, Linus does have a point - I can't start a new with Kconfig and > generate a working defconfig first time mainly because of the > thounds of options there. > > What I can do is get the ARM side of the configuration right, since > for the majority of cases the only thing that needs doing is selecting > the platform class and the board itself. > > The problem comes with driver configuration, where you have to go > through lots of menus to find all the drivers for the platform/SoC. > That's the tedious bit, and more often than not it takes several > attempts to get everything that's necessary. Would the resulting kconfig files that Linus is proposing (or whatever else goes in) be stable enough across different kernel versions that the hardware vendors could create them when the hardware is created and make them available? I'm not just thinking the ARM embedded space here, I'm also thinking things like laptops/notebooks which tend to have some unusual hardware as well. having a 'this is enough to see everything on the system' config would be a wonderful starting place to have. David Lang ^ permalink raw reply [flat|nested] 133+ messages in thread
end of thread, other threads:[~2010-07-14 17:37 UTC | newest] Thread overview: 133+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20100603074548.GA12104@flint.arm.linux.org.uk> 2010-06-03 14:48 ` ARM defconfig files Linus Torvalds 2010-06-03 16:46 ` Tony Lindgren 2010-06-03 18:13 ` Russell King 2010-06-03 21:33 ` Tony Lindgren 2010-06-03 22:45 ` Nicolas Pitre 2010-06-04 4:59 ` Tony Lindgren 2010-06-04 0:23 ` Kevin Hilman 2010-06-04 4:53 ` Tony Lindgren 2010-06-04 1:02 ` Benjamin Herrenschmidt 2010-06-04 5:29 ` Tony Lindgren 2010-06-04 6:30 ` Geert Uytterhoeven 2010-06-04 6:53 ` Geert Uytterhoeven 2010-06-04 8:52 ` Benjamin Herrenschmidt 2010-06-03 16:53 ` Daniel Walker 2010-06-08 15:30 ` Catalin Marinas 2010-06-08 16:37 ` Daniel Walker 2010-06-03 18:10 ` Russell King 2010-06-03 18:18 ` Linus Torvalds 2010-06-03 18:53 ` Russell King 2010-06-03 18:56 ` Linus Torvalds 2010-06-03 19:20 ` Russell King 2010-06-03 19:35 ` Daniel Walker 2010-06-03 19:45 ` Russell King 2010-06-03 19:49 ` Daniel Walker 2010-06-03 19:57 ` Russell King 2010-06-03 20:06 ` Daniel Walker 2010-06-03 20:18 ` Russell King 2010-06-03 20:20 ` Nicolas Pitre 2010-06-04 1:06 ` Benjamin Herrenschmidt 2010-06-03 20:09 ` Linus Torvalds 2010-06-03 20:31 ` Linus Torvalds 2010-06-03 21:17 ` Tony Lindgren 2010-06-03 22:15 ` Grant Likely 2010-06-04 5:18 ` Felipe Balbi 2010-06-04 11:31 ` Catalin Marinas 2010-06-03 22:24 ` Daniel Walker 2010-06-05 14:12 ` Felipe Contreras 2010-06-05 14:39 ` Linus Torvalds 2010-06-05 16:39 ` Felipe Contreras 2010-06-03 21:48 ` Daniel Walker 2010-06-04 0:36 ` Paul Mackerras 2010-06-04 12:39 ` Grant Likely 2010-06-05 13:47 ` Felipe Contreras 2010-06-03 20:34 ` Nicolas Pitre 2010-06-03 20:05 ` Linus Torvalds 2010-06-06 3:28 ` david 2010-06-03 18:20 ` Daniel Walker 2010-06-03 18:21 ` Linus Torvalds 2010-06-03 18:30 ` Al Viro 2010-06-03 19:26 ` Paul Mundt 2010-06-14 8:32 ` Uwe Kleine-König 2010-06-14 8:32 ` Uwe Kleine-König 2010-06-30 10:40 ` Uwe Kleine-König 2010-06-30 10:40 ` Uwe Kleine-König 2010-07-12 15:55 ` Uwe Kleine-König 2010-07-12 15:55 ` Uwe Kleine-König 2010-07-12 16:51 ` Linus Torvalds 2010-07-12 16:51 ` Linus Torvalds 2010-07-12 16:51 ` Linus Torvalds 2010-07-12 17:32 ` Russell King - ARM Linux 2010-07-12 17:32 ` Russell King - ARM Linux 2010-07-12 17:40 ` Linus Torvalds 2010-07-12 17:40 ` Linus Torvalds 2010-07-12 17:40 ` Linus Torvalds 2010-07-12 18:50 ` Uwe Kleine-König 2010-07-12 18:50 ` Uwe Kleine-König 2010-07-12 18:50 ` Uwe Kleine-König 2010-07-12 19:04 ` Linus Torvalds 2010-07-12 19:04 ` Linus Torvalds 2010-07-12 19:17 ` Nicolas Pitre 2010-07-12 19:17 ` Nicolas Pitre 2010-07-12 19:34 ` Linus Torvalds 2010-07-12 19:34 ` Linus Torvalds 2010-07-12 19:34 ` Linus Torvalds 2010-07-12 19:50 ` Grant Likely 2010-07-12 19:50 ` Grant Likely 2010-07-13 7:07 ` Uwe Kleine-König 2010-07-13 7:07 ` Uwe Kleine-König 2010-07-13 8:07 ` optimized script [Was: ARM defconfig files] Uwe Kleine-König 2010-07-13 8:07 ` Uwe Kleine-König 2010-07-13 8:07 ` Uwe Kleine-König 2010-07-13 18:04 ` Olof Johansson 2010-07-13 18:04 ` Olof Johansson 2010-07-13 18:04 ` Olof Johansson 2010-07-13 18:04 ` Olof Johansson 2010-07-13 23:39 ` Nicolas Pitre 2010-07-13 23:39 ` Nicolas Pitre 2010-07-13 23:39 ` Nicolas Pitre 2010-07-13 18:32 ` ARM defconfig files Grant Likely 2010-07-13 18:32 ` Grant Likely 2010-07-13 18:32 ` Grant Likely 2010-07-12 19:59 ` Uwe Kleine-König 2010-07-12 19:59 ` Uwe Kleine-König 2010-07-12 20:14 ` Nicolas Pitre 2010-07-12 20:14 ` Nicolas Pitre 2010-07-12 19:09 ` Nicolas Pitre 2010-07-12 19:09 ` Nicolas Pitre 2010-07-12 20:31 ` Arnd Bergmann 2010-07-12 20:31 ` Arnd Bergmann 2010-07-12 20:50 ` Nicolas Pitre 2010-07-12 20:50 ` Nicolas Pitre 2010-07-12 20:50 ` Nicolas Pitre 2010-07-12 23:05 ` David Brown 2010-07-12 23:05 ` David Brown 2010-07-12 23:18 ` Linus Torvalds 2010-07-12 23:18 ` Linus Torvalds 2010-07-12 23:18 ` Linus Torvalds 2010-07-12 23:34 ` David Brown 2010-07-12 23:34 ` David Brown 2010-07-13 0:55 ` Nicolas Pitre 2010-07-13 0:55 ` Nicolas Pitre 2010-07-14 9:13 ` Felipe Contreras 2010-07-14 9:13 ` Felipe Contreras 2010-07-14 13:20 ` Uwe Kleine-König 2010-07-14 13:20 ` Uwe Kleine-König 2010-07-14 13:20 ` Uwe Kleine-König 2010-07-14 17:37 ` Tony Luck 2010-07-14 17:37 ` Tony Luck 2010-07-14 17:37 ` Tony Luck 2010-07-13 18:32 ` Rob Landley 2010-07-13 18:32 ` Rob Landley 2010-07-12 20:06 ` Russell King - ARM Linux 2010-07-12 20:06 ` Russell King - ARM Linux 2010-07-12 20:29 ` Nicolas Pitre 2010-07-12 20:29 ` Nicolas Pitre 2010-07-12 21:54 ` Linus Torvalds 2010-07-12 21:54 ` Linus Torvalds 2010-07-14 9:21 ` Felipe Contreras 2010-07-14 9:21 ` Felipe Contreras 2010-07-14 9:21 ` Felipe Contreras 2010-06-03 18:41 ` Russell King 2010-06-03 18:53 ` Linus Torvalds 2010-06-06 3:53 ` david
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.