On 13-11-13 10:41 AM, Darren Hart wrote:
On Wed, 2013-11-13 at 10:23 -0500, Bruce Ashfield wrote:
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 :)
In that case, having fewer IA branches is more in keeping with the
Intel's goals for BSP management. Single-Image, single sources, no
vendor trees. I'll respin the series, dropping the branch in the minnow
scc files.
Some documentation needs to be updated... I'll have to own that.
And should I expect a v3 with the removal of the branch ?
Bruce
--
Darren
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.
_______________________________________________
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
