Re: ARM defconfig files
On Tue, Jul 13, 2010 at 2:34 AM, David Brown dav...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 11:06 PM, Russell King - ARM Linux li...@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 li...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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 dav...@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/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
2010/7/14 Uwe Kleine-König u.kleine-koe...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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 torva...@linux-foundation.org wrote: On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@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/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Monday 12 July 2010 18:18:01 Linus Torvalds wrote: 2010/7/12 David Brown dav...@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-de...@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. 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 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
Re: ARM defconfig files
2010/7/13 Uwe Kleine-König u.kleine-koe...@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 torva...@linux-foundation.org wrote: On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
2010/7/12 Uwe Kleine-König u.kleine-koe...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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 li...@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
Re: ARM defconfig files
2010/7/12 Uwe Kleine-König u.kleine-koe...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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 |
Re: ARM defconfig files
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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 n...@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/ |
#! /usr/bin/env python
# vim: set fileencoding=utf-8 :
# Copyright (C) 2010 by Uwe Kleine-König u.kleine-koe...@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()
Re: ARM defconfig files
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 li...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Mon, 12 Jul 2010, Linus Torvalds wrote: On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@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
Re: ARM defconfig files
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 1:29 PM, Nicolas Pitre n...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
2010/7/12 David Brown dav...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: 2010/7/12 David Brown dav...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Mon, 12 Jul 2010, David Brown wrote: On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: 2010/7/12 David Brown dav...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
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 |
