public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
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

  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$(echo .)net \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    --cc=m8@semihalf$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox