Sunday, January 1, 2012

MontaVista’s Contribution to The Yocto Project

MontaVista recently contributed code to the Yocto Project.  Following is a short interview with the MontaVista developer, Jeremy Puhlman discussing this contribution:

Can you describe the code contribution made to the Yocto Project?

MontaVista has made two main code contributions to the Yocto project.  The first deals with remote layering in BitBake and the second with layer management. Note that the terms collections and layers can be used interchangeably. Collections and layers are conceptually identical, but layers are implemented at the BitBake level, and collections are implemented at the metadata level.

* Remote layering

Back when MontaVista started working with BitBake we implemented the amend.bblass and collections.inc features to simplify how we run our business and our development. Both features were pushed back into what is now OpenEmbedded Classic. Both features were powerful and simple. The primary problem with both was that they existed primarily in the content, thus there was always a bit of fragility in how it all worked together.

In the intervening couple of years, the OpenEmbedded community has mostly moved those features into BitBake proper. During that same time MontaVista enhanced the collections feature, such that a collection could be a proper URI, rather then just a directory path. This functionality did not make it back into the upstream community code.  MontaVista’s submission to the Yocto/BitBake code stream proposed to add the URI feature into the BitBake layers implementation of collections.

The exact patch that was submitted was not accepted, but it was a good starting point to the discussion about supporting remote layers. Yocto Project members Paul Eggleton, Richard Purdie and I have had ongoing discussions about the various pieces of remote layers and how they come together. I think the final implementation of remote layering support will work for everyone involved. Paul has done a superb job at bring all of the issues together and putting something out that we can all work with as a community.

* Layer management

One of the key items that has been lacking in the community code base since collections were first pushed to OpenEmbedded, was an effective manner to manage which collections are in a given build project. However, it was never a big burning issue, because OpenEmbedded classic is one giant repository, so there wasn’t much to manage, even if you were using collections. What you were adding as a secondary collection tended to be much smaller and most likely non-overlapping.

When MontaVista developed the MVL6 product based on OpenEmbedded, we decided to take a much more modular approach to how MontaVista provided content to our customers. Once we got down to breaking up content into a core set of functionally coherent collections, MontaVista needed a set of tools to handle their management for people who know very little about all the inner-workings of BitBake and OpenEmbedded content. Our first iteration of those management tools were very MontaVista-centric, over time we have made our content management tools generic enough that they could be useful to a non-MontaVista customer/user.

Fast forward to the beginning of the Yocto Project. From its inception, Yocto, whether intentionally or otherwise, has adopted the model MontaVista provides to our customers. From breaking up the gigantic collection that is OpenEmbedded Classic into OpenEmbedded-core and sublayers like meta-oe, meta-intel, etc. and focusing on a layered approach to development.  Naturally, MontaVista saw places where we had already made progress and had experience such that we could provide code and guidance given that we had previously encountered similar or the same issues.

One of the major gaps was/is layer management. MontaVista provided an unbranded version of our content management tools with some tweeks to work with layers, rather the collections, as a means to provide a good foundation and starting point for the final community implementation.

* Why

There are a number of reasons why MontaVista contributed code to the community project. The primary one is that MontaVista wants to be a good member of the community and for various reasons we have not been able to be as good as we desired to be. Yocto is moving the community in a new direction and is supplying the work force to do it. Since MontaVista has been using the Yocto model long before Yocto existed, we had a stable of technologies and experiences that would be especially useful in the overall new direction. One of the primary ideas behind Yocto was to reduce the number of inventions and reinventions of the same technologies. The delivery of remote layering and layer management works in both those regards. From a purely technical standpoint, the contribution seemed obvious.

Given that the Yocto Project is open, can the contributed code be found in the Yocto codebase now?

Yocto itself has a limited code base. Most of the “Yocto” code has been going into the community repositories(BitBake, OpenEmbedded-core). The remote layer handling code is still on a development branch, I believe, and not in the mainline. However, our final marks on that code will be inspirational and collaborative, rather then “we wrote these lines of code”. I am not sure a preliminary version of the yocto layer management tools have been released, so I am not entirely sure about that one.

Will MontaVista be actively maintaining this code within the Yocto Project going forward, or is the hope that the community will dive in?

MontaVista’s involvement for those components was more of a here is how we did it, it would be a good starting point, but ultimately what we gave Yocto will not be the final results. Paul is the primary point of contact for those bits. More then anything it was a discussion about making sure specific usage models were addressed so we could be more closely connected to the community in the future.

For additional reading, please see Jeremy Puhlman – Developer Spotlight.


View the original article here