Category Archives: Meld Bytes

In late October 2011 I had the opportunity to attend the Embedded Linux Conference Europe (ELCE) in Prague, Czech Republic as a representative of the elinux.org community, sponsored by Linux Foundation.  As a new member of the MontaVista team, I’d attended the North American version of the same conference in San Francisco in April 2011 and made an effort to meet up with as many Meld.org community members as possible and spread the word about current and upcoming MontaVista Linux SDKs.  At ELCE, I continued this effort and tried to engage in conversation with community members to understand what they wanted from an embedded Linux online community.  Although I was sidelined for some time with illness, I did my best to attend as much as I could.  It was a challenging conference for me, but I was grateful for the opportunity and to share my impressions here.

The theme of ELCE was centered around the 20th anniversary of Linux.  In attendance were community personalities including Linus Torvalds, Dirk Hohndel, Theodore Ts’o, Alan Cox, etc. etc.  To list all the kernel developers present would take an article unto itself.  Needless to say, the presence of so many Linux “celebrities” added a certain buzz to the conference.  The opening keynote kernel panel consisted of Linus, Alan Cox, Thomas Gleixner, and Paul McKenney being subjected to Questions from both the moderator, Lennart Poettering and audience members.  What I assumed would be a discussion of present technical issues in kernel development and glimpses into the future turned into a discussion about the inevitable ageing of the core kernel development team.  Although this wasn’t the content I was hoping for, it is a somewhat contentious subject within the kernel development community.  My impression from the answers given by Linus and the like is that it’s not really an issue at all.  Yes, core developers are ageing, but there are many new, young developers participating as well.  The general idea that a young developer can simply jump into kernel development and contribute significantly is waning as the kernel grows in complexity.  Not to say that the latter is impossible, it’s just become less common.  However, the young kernel hackers are climbing the kernel development learning curve, it’s just that the curve has increased.

Another interesting amount of content centered around the history of Linux, and in particular the experiences of kernel developers in the early days.  Dirk Hohndel presented a Day 2 keynote describing his experiences in those early days.  Dirk stressed that in those days there was no grand plan of world domination, no prescient ideas about where Linux could go, but rather a series of challenging, fun technical problems that needed to be solved.  He, Linus and the other early contributors were having fun.  Each day consisted of trying to see what problem could be solved that day, like getting a new piece of hardware to come up, or adding a new tool.  Community was always the key to the success of Linux.

Most of the big players in the Embedded Linux space were present at ELCE.  The Yocto Project, Linaro, RedHat, Intel, Texas Instruments, Sony, etc. etc. indicating that a lot of Embedded Linux development continues to be sponsored by these organizations.  MontaVista played a role as well, with developer Klaas van Gend hosting the closing comments and games.  Klaas bravely opened a web server to gather game answers during the closing session which was playfully hacked by a member of the crowd.  But Klaas was not deterred, restored his server and soldiered on with a very entertaining closing session.

The 2011 Embedded Linux Conference Europe was a qualified success for me, even though I was not able to attend many talks due to illness.  The Embedded Linux community presence was strong, demonstrating its health and the continued growth of Embedded Linux development everywhere.
Linux Foundation will hold the next Embedded Linux Conference in Redwood Shores, California from February 15th-17th, 2012.

* Presentation from ELCE can be found on the elinux.org wiki.

* The conference schedule can be found on the Linux Foundation event page.

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.