From: Tony Lindgren <tony@atomide.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Vincent Sanders <vince@simtec.co.uk>,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH] Remove ARM default configurations which duplicate omap3_defconfig
Date: Wed, 4 Aug 2010 15:35:34 +0300 [thread overview]
Message-ID: <20100804123533.GN9881@atomide.com> (raw)
In-Reply-To: <20100804113047.GA6852@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [100804 14:24]:
> On Wed, Aug 04, 2010 at 08:35:36AM +0300, Tony Lindgren wrote:
> > * Vincent Sanders <vince@simtec.co.uk> [100803 23:23]:
> > > These configurations are no longer useful as the systems they support
> > > are covered by the generic omap3_defconfig
> >
> > Since the defconfigs will stay around at least for a while
> > in the compacted form..
> >
> > .. And until we have sorted out how to deal with which drivers
> > need to be compiled in or as modules for each board, I'd
> > rather keep these defconfigs around for now.
>
> That's a user optimization more than anything else.
>
> > Can we just disable building these with some blacklist
> > in Kautobuild?
>
> That's no the point. The point is that there's too many of these things.
> Most other SoCs get away with far fewer defconfigs than OMAP does, and I
> don't see why OMAP should get any kind of special treatment on this.
>
> > So Not-yet-acked-by until some Kconfig issues are sorted out :)
>
> We've known that the defconfig situation is a hot potato since just
> after the last merge window, and we should consider ourselves lucky
> that through Uwe's work, Linus has stepped back from removing all
> the defconfigs. Had that not happened, we would now be looking at
> all the defconfigs being removed.
>
> I've also been on at people throughout the last three months over this
> issue, and it's gained very little traction. What's waiting another
> three months going to achieve? All that I can see is it'll just be a
> delay of execution.
>
> So, I'm going to give it a week, and then I'm applying this patch. As
> Linus said when he was talking about removing all the defconfigs, if
> people want to keep them around, put them on a website or similar. We've
> already had enough time to sort something out.
OK, fine. I'll add it to omap-for-linus and merge it. No need to
wait a week on this.
With the recent changes all known mach-omap2 boards should
be now bootable with just:
$ rm .config
$ echo CONFIG_ARCH_OMAP=y > .config
$ yes "" | ARCH=arm make oldconfig
Of course the drivers still need to be selected and CMDLINE needs
to be set for some boards not suporting bootloader cmdline options.
And CONFIG_SMP can't be selected on uncore boards.
Cheers,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Remove ARM default configurations which duplicate omap3_defconfig
Date: Wed, 4 Aug 2010 15:35:34 +0300 [thread overview]
Message-ID: <20100804123533.GN9881@atomide.com> (raw)
In-Reply-To: <20100804113047.GA6852@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [100804 14:24]:
> On Wed, Aug 04, 2010 at 08:35:36AM +0300, Tony Lindgren wrote:
> > * Vincent Sanders <vince@simtec.co.uk> [100803 23:23]:
> > > These configurations are no longer useful as the systems they support
> > > are covered by the generic omap3_defconfig
> >
> > Since the defconfigs will stay around at least for a while
> > in the compacted form..
> >
> > .. And until we have sorted out how to deal with which drivers
> > need to be compiled in or as modules for each board, I'd
> > rather keep these defconfigs around for now.
>
> That's a user optimization more than anything else.
>
> > Can we just disable building these with some blacklist
> > in Kautobuild?
>
> That's no the point. The point is that there's too many of these things.
> Most other SoCs get away with far fewer defconfigs than OMAP does, and I
> don't see why OMAP should get any kind of special treatment on this.
>
> > So Not-yet-acked-by until some Kconfig issues are sorted out :)
>
> We've known that the defconfig situation is a hot potato since just
> after the last merge window, and we should consider ourselves lucky
> that through Uwe's work, Linus has stepped back from removing all
> the defconfigs. Had that not happened, we would now be looking at
> all the defconfigs being removed.
>
> I've also been on at people throughout the last three months over this
> issue, and it's gained very little traction. What's waiting another
> three months going to achieve? All that I can see is it'll just be a
> delay of execution.
>
> So, I'm going to give it a week, and then I'm applying this patch. As
> Linus said when he was talking about removing all the defconfigs, if
> people want to keep them around, put them on a website or similar. We've
> already had enough time to sort something out.
OK, fine. I'll add it to omap-for-linus and merge it. No need to
wait a week on this.
With the recent changes all known mach-omap2 boards should
be now bootable with just:
$ rm .config
$ echo CONFIG_ARCH_OMAP=y > .config
$ yes "" | ARCH=arm make oldconfig
Of course the drivers still need to be selected and CMDLINE needs
to be set for some boards not suporting bootloader cmdline options.
And CONFIG_SMP can't be selected on uncore boards.
Cheers,
Tony
next prev parent reply other threads:[~2010-08-04 12:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 20:19 [PATCH] Remove ARM default configurations which duplicate omap3_defconfig Vincent Sanders
2010-08-04 5:35 ` Tony Lindgren
2010-08-04 11:01 ` Vincent Sanders
2010-08-04 11:25 ` Tony Lindgren
2010-08-04 11:30 ` Russell King - ARM Linux
2010-08-04 12:35 ` Tony Lindgren [this message]
2010-08-04 12:35 ` Tony Lindgren
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=20100804123533.GN9881@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=vince@simtec.co.uk \
/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: link
Be 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.