From: Olof Johansson <olof@lixom.net>
To: Marian Balakowicz <m8@semihalf.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [POWERPC] Update TQM5200, CM5200 and Motion-PRO _defconfig and .dts files
Date: Thu, 17 Jan 2008 21:41:03 -0600 [thread overview]
Message-ID: <20080118034103.GA17898@lixom.net> (raw)
In-Reply-To: <478FD118.8030407@semihalf.com>
On Thu, Jan 17, 2008 at 11:05:12PM +0100, Marian Balakowicz wrote:
> Grant Likely wrote:
> > On 1/17/08, Marian Balakowicz <m8@semihalf.com> wrote:
> >> Grant Likely wrote:
> >>> On 1/17/08, Marian Balakowicz <m8@semihalf.com> wrote:
> ...
> >>> Can you split the defconfig changes into a separate patch... That
> >>> being said, how do you feel about merging all the 5200 defconfigs into
> >>> a single defconfig? They are all multiplatform after all and it would
> >>> make maintenance easier.
> >> Ok, I'll split it into two patches.
> >>
> >> But merging defconfigs won't be a good option, boards differ in which
> >> devices they use, some have PCI, some have USB, etc. Having one
> >> defconfig, it would be necessary to manually customize kernel
> >> configuration and remember which options are to be set/disabled.
> >
> > That doesn't matter for defconfigs. That needs to be done when you're
> > tailoring a product regardless. defconfigs are simply a known good
> > configuration; they are not intended to be the deployed config. If
> > the defconfig enables all features used by any of the boards then it
> > should be okay.
>
> That's true, defconfigs are only reference configurations, but still,
> I would opt for a separate defconfigs as it is more clear which target
> given defconfig is meant for and it is more convenient for development
> and customer to have it separate. And IMHO it's actually easier to
> maintain, as you don't need to consider all three boards each time you
> update defconfig and don't need to test each defconfig change on three
> (right now) boards, etc.
I disagree, I have one defconfig for all our boards to date. It means I
only have one kernel to build to test on all boards, instead of having
to build a number of different kernels. Keeping it fairly generic also
means a customer can start out using the generic kernel in case they
want to, and later on add their own drivers and prune out what is not
needed.
-Olof
next prev parent reply other threads:[~2008-01-18 3:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 14:31 [PATCH] [POWERPC] Update TQM5200, CM5200 and Motion-PRO _defconfig and .dts files Marian Balakowicz
2008-01-17 16:05 ` Grant Likely
2008-01-17 18:02 ` Marian Balakowicz
2008-01-17 18:23 ` Grant Likely
2008-01-17 22:05 ` Marian Balakowicz
2008-01-18 3:41 ` Olof Johansson [this message]
2008-01-23 11:31 ` Marian Balakowicz
2008-01-23 12:54 ` Wolfgang Denk
2008-01-23 16:27 ` Grant Likely
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=20080118034103.GA17898@lixom.net \
--to=olof@lixom.net \
--cc=linuxppc-dev@ozlabs.org \
--cc=m8@semihalf.com \
/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.