So what do you do when you get a new toy? You race around trying out all of the fun stuff you can do with it, of course. It is no different with me now that MVL6 is in beta and being used by developers.

As previously mentioned the integration platform capability of MVL6 is a big new feature. My last post mentioned many of the benefits including more easily reproducible builds and clear traceability of all build inputs to the outputs. A simplified diagram of the system looks like this:

The entire process is controlled by recipes and there is full transparency and traceability between source and metadata inputs and the build products that are produced. What kind of build products are there? Quite a few, in fact.

• Prebuilt filesystems that can be deployed to targets
• Packages in a variety of formats that can be used for deployed device upgrades
• Various manifest files describing what was placed in the built images
• Original source archives and patches suitable for distribution to satisfy various licensing obligations

As an example, after doing a quick test build of the busybox and less software packages you can see the source code ready for distribution:

$ ls tmp/deploy/sources/*/tmp/deploy/sources/BSD/:

less-418.tar.gz  less-418.tar.gz.md5tmp/deploy/sources/GPL/:

busybox-1.13.2-depmod.patch      busybox-1.13.2-modprobe.patch

busybox-1.13.2-depmod.patch.md5  busybox-1.13.2-modprobe.patch.md5

busybox-1.13.2-init.patch        busybox-1.13.2.tar.gz

busybox-1.13.2-init.patch.md5    busybox-1.13.2.tar.gz.md5

busybox-1.13.2-mdev.patch        busybox-1.13.2-tar.patch

busybox-1.13.2-mdev.patch.md5    busybox-1.13.2-tar.patch.md5

Is that source tarball actually the real original unmodified source from the upstream project? Let’s check and see by verifying the cryptographic signatures:

$ cp tmp/deploy/sources/BSD/less-418.tar.gz ./
$ wget ftp://ftp.gnu.org/gnu/less/less-418.tar.gz.sig
$ gpg -v less-418.tar.gz.sig
gpg: assuming signed data in `less-418.tar.gz'
gpg: Signature made Tue 08 Jan 2008 05:18:56 PM EST using DSA key ID 33235259
gpg: requesting key 33235259 from hkp server subkeys.pgp.net
gpg: armor header: Version: SKS 1.0.9
gpg: pub  1024D/33235259 2004-12-04  Mark Nudelman <markn@greenwoodsoftware.com>
gpg: using classic trust model
gpg: key 33235259: public key "Mark Nudelman <markn@greenwoodsoftware.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Good signature from "Mark Nudelman <markn@greenwoodsoftware.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: AE27 252B D684 6E7D 6EAE  1DD6 F153 A7C8 3323 5259
gpg: binary signature, digest algorithm SHA1

That looks good. How about busybox?

$ cp tmp/deploy/sources/GPL/busybox-1.13.2.tar.bz2 ./
$ wget http://www.busybox.net/downloads/busybox-1.13.2.tar.bz2.sign
$ gpg -v busybox-1.13.2.tar.bz2.sign
gpg: armor header: Hash: SHA1
gpg: armor header: Version: GnuPG v1.4.6 (GNU/Linux)
gpg: original file name=''
gpg: Signature made Tue 30 Dec 2008 10:37:37 PM EST using DSA key ID ACC9965B
gpg: requesting key ACC9965B from hkp server subkeys.pgp.net
gpg: armor header: Version: SKS 1.0.9
gpg: pub  1024D/ACC9965B 2006-12-12  Denis Vlasenko <vda.linux@googlemail.com>
gpg: using classic trust model
gpg: key ACC9965B: public key "Denis Vlasenko <vda.linux@googlemail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Good signature from "Denis Vlasenko <vda.linux@googlemail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C9E9 416F 76E6 10DB D09D  040F 47B7 0C55 ACC9 965B
gpg: textmode signature, digest algorithm SHA1

That checks out, too.

Now your developers and management can be assured that when it comes time satisfy any license obligations you have an easy and repeatable process for ensuring that the sources corresponding to distributed binaries is at hand.

If you’ve read up on MVL6 you’ve seen that we describe the BitBake tool as being used as the core of our new MontaVista Integration Platform. I’d like to explain what that means, from a technical standpoint, and how it rocks.

OpenEmbedded (OE) is a widely used, and I would consider a defacto standard, for community engineered embedded Linux distributions. OE is has been around for 7+ years and has an active contributor base of both commercial, independent contractor, and enthusiast developers. OE is what I call a family of related Linux distributions that share some common infrastructure. Each development team then customizes their distribution to meet their requirements. Some examples.

BitBake is one of these common infrastructure tools. BitBake is analogous to “make”. BitBake analyzes a set of directives and then builds a task dependency tree to satisfy a user command. BitBake then executes the defined tasks to completion. When paired with the OE metadata BitBake can compile from source to create the host development tools, cross-development tools, target binaries, and system flash/disk images needed.

On a technical basis MVL6 is, because of our use of BitBake and compatibility with the BitBake recipe syntax and the OE metadata, a peer to other OpenEmbedded-style distributions as listed above. Just like these peer distributions MVL6 has unique requirements driven by our customers.

For the MVL6 development tools we’ve invested to create several compelling benefits for developers over every option on the market both commercial and non-commercial:

• Dirt simple and fast installation. MVL6 is the fastest and easiest embedded Linux distribution to install and get productive in. I’ve used a bunch of them… commercial and non-commercial. Trust me on this. We’ve got a small required core to install and everything past that can be done incrementally on demand.
• It just works. When I interviewed developers about their experiences using several prominent community embedded Linux distributions there was a clear and consistent message: They were hard to use and took a lot of help and tweaking to get going. It is infuriating to kick off a build only to see it fail 7 hours into an 8 hour process because you were missing some important host tool or a website with the source code went down. MVL6 gets you started fast with sensible defaults, prebuilt binaries, and a quick path to get your hardware booted.
• One file defines your design. Using the extensions we’ve added you can use a single configuration file to define your entire design. We’ve got helpful docs to explain how to customize your project while not making an un-maintainable mess.
• MVL6 can start small and build up incrementally. Sometimes developers have to squeeze their designs to fit into flash. MVL6 starts with a small image and lets developers add incrementally. They can even break the bounds of restrictive binary-only distributions and downsize within software packages by removing features or files.
• MVL6 doesn’t cut you off from the world. While we provide a complete Market Specific Distribution (MSD) for your design you can, if you wish, supplement our product with components from OpenEmbedded. We’ve retained compatibility to give you great options.
• MVL6 doesn’t lock you in. Most commercial embedded Linux build systems are either under an ambiguous proprietary license or are so esoteric to be classified as vendorscript. MVL6 won’t lock you in like that due to its open core and usage of a defacto standard recipe syntax.
• A logical update system. MontaVista periodically releases updated software components to fix bugs and offer enhancements. Getting these updates into your MVL6 project is simple and risk free. Lock your project down so version updates don’t happen without permission. Pull down the updates using a simple automated tool. Try them out by commenting the version lockdown line. If you don’t like it just uncomment the version lockdown and no harm done.
• Works great behind a network proxy or even offline. Often developers have to work on restricted lab networks. Rather than depending on a slew of public HTTP, CVS, git, and Subversion servers across the Internet there is a single source for every original source archive and patch that goes into your MVL6 powered product. You can access the MontaVista Zone (MVZ) Content Server from behind a proxy or quickly mirror it for your own offline operations.
• We don’t even lock you into MVZ. Let’s say its 2018 and after the Great Quake of California that flooded the Bay Area you want to update your MVL6 powered design with some additional software. You forgot to download the sources for the libfoo package and now MontaVista is at the bottom of Lake Santa Clara. Luckily the MVL6 Integration Platform is smart enough to go to the original upstream repository. You go on as a happy developer.
• Better build portability. Often our customers need to be able to reproduce their builds for 10+ years into the future. The problem is that as their development PC’s get replaced they have to upgrade to new host Linux distributions. We’ve made sure MVL6 depends only on the well defined Linux Standard Base (LSB) components of the host operating system. This assures developers that, to the extent that is feasible without a crystal ball, their builds will be reproducible on future Linux distributions that have not yet been created.
• Better build reproducibility. What builds today has to build in 10 years. We’ve got MVL6 dialed-in so you can easily configuration manage the system without having to check 100,000 files into your revision control system. That’s goodness.

So that’s a long little love letter for the product. There are lots more cool tricks to show. Mark you calendars for an upcoming webinar by my esteemed colleague Nick Pollitt on all manners of MVL6-foo.