[linux-yocto] [PATCH v2 0/4][3.10][meta] MinnowBoard and Wifi updates

[Bruce Ashfield]

On 13-11-13 01:59 AM, Darren Hart wrote:
> On Tue, 2013-11-12 at 23:18 -0500, Bruce Ashfield wrote:
>> On 11/12/2013, 4:27 PM, Darren Hart wrote:
>>> On Tue, 2013-11-12 at 15:59 -0500, Bruce Ashfield wrote:
>>>> On 13-11-11 06:25 PM, Darren Hart wrote:
>>>>> The following changes since commit f1c9080cd27f99700fa59b5375d1ddd0afe625ad:
>>>>>
>>>>>      meta/common-pc: add missing dependencies for BRCMSMAC (2013-11-03 23:01:35 -0500)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>>      git://git.yoctoproject.org/linux-yocto-contrib dvhart/3.10/meta
>>>>>      http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=dvhart/3.10/meta
>>>>>
>>>>> Darren Hart (4):
>>>>>      minnow: Remove eg20t
>>>>>      minnow-io: Add feature for MinnowBoard GPIO keys and LEDs
>>>>>      minnow: Remove old patches for Ethernet and GPIO
>>>>
>>>> To confirm. We still want standard/minnow to contain these changes ?
>>>> That's what the meta data tells me, but I wanted to be sure.
>>>
>>> No, the new BSP will use standard/base. There is no real need to have a
>>> standard/minnow branch as far as I can see.
>>
>> That's what I was wondering and thinking as well. When I was merging the
>> changes I noticed the minnow-standard.scc still had a branch statement.
>> Did you want to quickly roll that removal into this series while you
>> are updating the meta data ?
>
> I hadn't thought of this. I thought the purpose of the branch statement
> in the minnow BSP scc was to provide a starting point to add anything
> the kernel BSP or the recipe BSP added to the kernel sources -
> independent of whether or not the standard/branch actually existed.

The branch will be created when the statement is processed. If anything
happens after the statement, the changes go on that branch.

So by just having it there, you are creating a placeholder branch.

It is trivial to create the branch later if there really is custom
content. So if you don't want to have it sitting there, then drop
the branch statement for now.

There are definitely two schools of thought on this. Those that want
to just build from a common branch, and those that follow the
'branches are simple and cheap' and they document what boards are
supported .. so use them and be happy.

The tools support both, and we can do either. In different contexts
I'm opinionated one way or the other :)

>
> I don't know what best practice is here - maybe we're establishing it
> now. What would you suggest?

see above.

>
>>
>>>
>>> I suppose ultimately the BSP branches from standard/base and then
>>> applies the minnow-io feature, but that is meant to be optional at the
>>> BSP (recipe-space) level.
>>>
>>> I'd like *ALL* Intel BSPs to ultimately build from standard/base.
>>>
>>> So - is there any reason to have standard/minnow lying around? I've
>>> removed it from my test builds.
>>
>> How are you working with the minnow-io feature ? I can answer the minnow-io
>> question and the fate of the branch with that answer :)
>
> I plan to have the minnow layer linux-yocto bbappend add minnow-io as a
> KERNEL_FEATURE. This makes it easy to leave it out (which is good as it
> is an abomination of boardfiles).

Aha.

The only issue you could run into here is that the patches will be
applied at build time. Which means that if I merge anything to the
base that conflicts, you need to refresh the patches. I hate build time
patch breakage .. since it is the last thing you want to see when just
trying to build a board.

The only alternative to avoid alternative is to get them on a branch
(*cough* standard/minnow-<foo>) or in that staging branch you had
before, and go with the git merge (but the merge can fail, but at
least the patches can be rebased on the branch to deal with the
conflict and everyone stays in sync).

Cheers,

Bruce

>
>>
>> I ask, because I didn't see it in the series being included or merged
>> (or did I miss it?) from the BSP .scc files themselves.
>
> Right, I didn't even think of it. Open to suggestions.
>
> My current thinking is that we should probably remove it from every BSP
> that starts using standard/base as its KBRANCH - this removes complexity
> from the BSP scc, and that is almost always a good thing in this space.
>