Config fragment for Versatile Express

[Jon Medhurst (Tixy)]

On Tue, 2012-04-03 at 09:13 +0800, Andy Green wrote:
> On 04/03/2012 02:58 AM, Somebody in the thread at some point said:
> > On Mon, 2012-04-02 at 11:18 -0700, John Stultz wrote:
> >> On 04/02/2012 10:29 AM, Jon Medhurst (Tixy) wrote:
> >>> On Mon, 2012-04-02 at 08:37 -0700, John Stultz wrote:
> >>>> On 03/31/2012 02:17 AM, Jon Medhurst (Tixy) wrote:
> >>>>> We almost certainly need board specific android and ubuntu fragments as
> >>>>> well, so I'll add vexpress-android.conf and vexpress-ubuntu.conf as
> >>>>> well. (Unless there is some magic to have conditional config options in
> >>>>> a fragment?)
> >>>>
> >>>> No, the config fragments are pretty simple, so there's no conditional
> >>>> logic in them. Your idea for a board-type.conf style split sounds like a
> >>>> fair idea. Although, I'm curious what would be an example of this?
> >>>
> >>> There's often let's-just-get-it-working hacks produced, and sometimes
> >>> you don't want to risk breaking other boards by putting things into a
> >>> common config.
> >>>
> >>> My example of this is
> >>> http://android.git.linaro.org/gitweb?p=kernel/vexpress-a9.git;a=commit;h=20a2abd40fff4d5942263c09b9852986c47aaa32
> >>>
> >>> Of course, this could be an argument for not enabling such things. ;-)
> >>
> >> Ok. Interesting. I can see how this sort of flexibility is useful. So 
> >> I'm fine if folks want to add board-distro specific tweaks. Trying to 
> >> find some more unified way of building might be necessary, so folks 
> >> aren't having to customize things too drastically. Your directory method 
> >> seems like would solve this, but I need to spend some more time 
> >> understanding Andy's suggestion and understanding how it works with 
> >> Andrey's centralized tree.
> > 
> > Possibly if we just had a symlink
> > 
> >     configs/omap_5430evm/base/main.conf -->
> >     arch/arm/configs/omap_5430evm_defconfig
> > 
> > but then that defconfig has some non board specific stuff, like EXT
> > file-systems configured. And Andrey's Android branch would have TI's
> > Android topics, so that 'base' defconfig file would also gain TI's
> > Android flavourings. (Neither of these issues might be a problem in
> > practice.)
> 
> It's really preferable to keep to one defconfig for everything but
> sometimes that won't be possible (you were saying you might need more
> than one for presumably very basic reasons).

It depends what more than one defconfig means. I was suggesting that we
have multiple fragments so topics could have there own fragment if
necessary, for when people don't have stacked topics to modify a single
defconfig. I also suggested it might be wise for a get-out-of-jail
method so a board could override distro options. (Perhaps the later
shouldn't be made part of the normal workflow and instead be a manual
hack applied by distro maintainer in exceptional circumstances.)

>   In that case the config
> deltas will need to be applied to n defconfigs as part of the rebase /
> merge process creating the output tree.
> 
> So it might be simpler instead of using multiple symlinks if the LT base
> tree creates and maintains a text file that is a list of "defconfigs
> this tree maintains" which will all get processed by the topic
> management scripts in turn for each config delta when the flavourings
> are added.

I though the distro building would be using merge_config.sh to generate
the .config for the build, therefore this would all just be as simple as
having it use the argument "my-board-config-directory/*" instead of
"my-board-config-file".

For most cases I would guess even "cat my-board-config-directory/*
>board.conf" would work. So perhaps we could allow each board to specify
a shell script to generate a config rather than coming up with a
mechanism we all agree on? We could also pass the distro as an argument
so the script could apply hacks as appropriate.

-- 
Tixy