From: Nicolas Pitre <nico@fluxnic.net> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Russell King - ARM Linux" <linux@arm.linux.org.uk>, "Daniel Walker" <dwalker@codeaurora.org>, "Kevin Hilman" <khilman@deeprootsystems.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Grant Likely" <grant.likely@secretlab.ca>, "Eric Miao" <eric.miao@canonical.com>, linux-omap@vger.kernel.org Subject: Re: ARM defconfig files Date: Mon, 12 Jul 2010 16:14:43 -0400 (EDT) [thread overview] Message-ID: <alpine.LFD.2.00.1007121545360.10598@xanadu.home> (raw) In-Reply-To: <AANLkTim-O00n9YPv7w4VCKjN-ETLijyTHomWUn4mZtTV@mail.gmail.com> [-- 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
WARNING: multiple messages have this Message-ID (diff)
From: nico@fluxnic.net (Nicolas Pitre) To: linux-arm-kernel@lists.infradead.org Subject: ARM defconfig files Date: Mon, 12 Jul 2010 16:14:43 -0400 (EDT) [thread overview] Message-ID: <alpine.LFD.2.00.1007121545360.10598@xanadu.home> (raw) In-Reply-To: <AANLkTim-O00n9YPv7w4VCKjN-ETLijyTHomWUn4mZtTV@mail.gmail.com> 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
next prev parent reply other threads:[~2010-07-12 20:14 UTC|newest] Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top [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 [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.LFD.2.00.1007121545360.10598@xanadu.home \ --to=nico@fluxnic.net \ --cc=dwalker@codeaurora.org \ --cc=eric.miao@canonical.com \ --cc=grant.likely@secretlab.ca \ --cc=khilman@deeprootsystems.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=torvalds@linux-foundation.org \ --cc=u.kleine-koenig@pengutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.