From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> To: Marc Dietrich <marvin24-Mmb7MZpHnFY@public.gmane.org> Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> Subject: Re: [PATCH] ARM: tegra: rebuild tegra_defconfig Date: Wed, 29 May 2013 11:42:19 -0600 [thread overview] Message-ID: <51A63DFB.3010206@wwwdotorg.org> (raw) In-Reply-To: <7367180.OaP1fIIt8z@ax5200p> On 05/29/2013 11:30 AM, Marc Dietrich wrote: > On Wednesday 29 May 2013 09:29:48 Stephen Warren wrote: >> On 05/29/2013 07:38 AM, Marc Dietrich wrote: >>> Am Dienstag, 28. Mai 2013, 15:30:29 schrieb Stephen Warren: >>>> On 05/28/2013 11:26 AM, Stephen Warren wrote: >>>>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> >>>>> >>>>> This simply rebuilds tegra_defconfig on top of next-20130520. As such, >>>>> it >>>>> should introduce no changes; simply moving entries around due to Kconfig >>>>> ordering changes. The apparent exceptions are: ... >>> This way we would have a >>> better chance to have a zero diff between defconfig and tegra_defconfig, >>> e.g. not like 3.10 is now. >> >> I don't understand this; what is "defconfig" if not "tegra_defconfig"? > > defconfig: make tegra_defconfig; make saveconfig > > diff -u tegra_defconfig defconfig Oh right. Yes, if you do that in the for-3.11/defconfig branch itself, there will be diffs. That will always be true; that branch won't have any of the new drivers/features that will be added in linux-next and the next mainline kernel, so at the very least you'd end up removing some options doing that. I expect most people editing defconfig will be doing it based on some linux-next version rather than right on top of for-3.11/defconfig, so they can pick up, enable, and test new drivers or features. If you run the commands above in next-20130529, there should be a zero diff (unless someone made some Kconfig changes between next-20130528 and next-20130529 anyway).
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM: tegra: rebuild tegra_defconfig Date: Wed, 29 May 2013 11:42:19 -0600 [thread overview] Message-ID: <51A63DFB.3010206@wwwdotorg.org> (raw) In-Reply-To: <7367180.OaP1fIIt8z@ax5200p> On 05/29/2013 11:30 AM, Marc Dietrich wrote: > On Wednesday 29 May 2013 09:29:48 Stephen Warren wrote: >> On 05/29/2013 07:38 AM, Marc Dietrich wrote: >>> Am Dienstag, 28. Mai 2013, 15:30:29 schrieb Stephen Warren: >>>> On 05/28/2013 11:26 AM, Stephen Warren wrote: >>>>> From: Stephen Warren <swarren@nvidia.com> >>>>> >>>>> This simply rebuilds tegra_defconfig on top of next-20130520. As such, >>>>> it >>>>> should introduce no changes; simply moving entries around due to Kconfig >>>>> ordering changes. The apparent exceptions are: ... >>> This way we would have a >>> better chance to have a zero diff between defconfig and tegra_defconfig, >>> e.g. not like 3.10 is now. >> >> I don't understand this; what is "defconfig" if not "tegra_defconfig"? > > defconfig: make tegra_defconfig; make saveconfig > > diff -u tegra_defconfig defconfig Oh right. Yes, if you do that in the for-3.11/defconfig branch itself, there will be diffs. That will always be true; that branch won't have any of the new drivers/features that will be added in linux-next and the next mainline kernel, so at the very least you'd end up removing some options doing that. I expect most people editing defconfig will be doing it based on some linux-next version rather than right on top of for-3.11/defconfig, so they can pick up, enable, and test new drivers or features. If you run the commands above in next-20130529, there should be a zero diff (unless someone made some Kconfig changes between next-20130528 and next-20130529 anyway).
next prev parent reply other threads:[~2013-05-29 17:42 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-28 17:26 [PATCH] ARM: tegra: rebuild tegra_defconfig Stephen Warren 2013-05-28 17:26 ` Stephen Warren 2013-05-28 21:30 ` Stephen Warren 2013-05-28 21:30 ` Stephen Warren [not found] ` <51A521F5.2010206-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-05-29 13:38 ` Marc Dietrich 2013-05-29 13:38 ` Marc Dietrich [not found] ` <2234363.J239kID5LN-D3pzGp0ZKuDWZbiwp4sFPyrtisivX6KghOMvlBiLbJSELgA04lAiVw@public.gmane.org> 2013-05-29 15:29 ` Stephen Warren 2013-05-29 15:29 ` Stephen Warren [not found] ` <51A61EEC.5040300-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-05-29 17:30 ` Marc Dietrich 2013-05-29 17:30 ` Marc Dietrich 2013-05-29 17:42 ` Stephen Warren [this message] 2013-05-29 17:42 ` Stephen Warren 2014-06-16 18:04 Stephen Warren 2014-06-16 18:04 ` Stephen Warren
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=51A63DFB.3010206@wwwdotorg.org \ --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=marvin24-Mmb7MZpHnFY@public.gmane.org \ --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ /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.