Keynote – Embedded Build Systems Panel – Tim Bird (Sony); Ross Burton (Intel); Thomas Petazzoni (Free Electrons); Karim Yaghmour (Opersys); Moderator: Jeff Osier-Mixon (Intel)

After introducing each of the build systems, the panel answers questions from the audience.

Buildroot is the oldest embedded build system. It was more or less abandoned in 2004, but picked up again in 2009. It uses two core technologies: Kconfig and make. It generates a standalone filesystem with no package manager and focuses on small systems and exotic architectures like Xtensa and Blackfin.

Yocto is so great because it is flexible. You can use e.g. a package manager. It can build a rootfs with a package manager, but also an SDK and Eclipse integration. It is a layer-based system, so you can use packages from many different layers and almost anything is available.

At the time that Tim needed a build system at Sony, nothing good was available – buildroot was there but not so great. At the time, the product divisions went and did their own thing, using various kernel provides (including montavista and timesys). So they made their own integration. Now teams are switching again, e.g. to yocto, but there’s a lot of inertia.

Android’s roots go back to the nineties: it draws on people who had been doing mobile stuff for a long time. This environment has a different mindset – they really want control of anything. This ends up turning Android into a completely different environment: bionic, the build system, etc.

Which build system will be the de-facto standard 10 years down the line?

Tim: it won’t be a new one, because the existing use cases are well covered. But there won’t be a clear winner, because of different requirements. Between buildroot and yocto, it depends on what you value as a developer. It’s faster to get up to speed with buildroot, but yocto has features that appeal to companies.

Thomas: it’s a vim vs. emacs discussion: it’s a matter of preference. There may be some consolidation because there are now a lot more than the ones mentioned here, but there will certainly be several tools around.

Karim: Android will eat the whole pie. Market drivers force towards Android, there are SoC vendors that only provide Android BSPs, not Linux. Currently buildroot and yocto allow things that are not possible on Android, but there will be creep. Thomas: but there are markets other than CE that have different requirements, and they still pull to something else. Karim: we’re increasingly seeing Android used on headless systems, just to have a single platform that can be used by all app developers and across all platforms. And it’s still possible to put a buildroot chroot in parallel. Ross: the problem is that Google controls it with an iron fist, and there will always be users that want to keep control.

How can I hack on a package in these build systems?

DIY: you do it yourself.

Buildroot/yocto: there is a way to take the source from externally instead of the upstream source.

yocto: you can also drop in a devshell in the package source directory, make local hacks and rebuild.

Android: nothing is there; Karim just does it externally and copies the build artifacts over into the Android image. Tim: but they’ve forced a uniformity on the inputs by putting everything in git/repo, but it is disassociated from the upstream projects.

GUIs for the build system and for the target

Tim: Sony was successful because they didn’t rely on external libraries for the GUI. The promise of the yocto project of mixing and matching layers doesn’t really deliver because the interfaces don’t match, e.g. you can’t build a gtk app on KDE.

Thomas: there’s xconfig, there’s an Eclipse plug-in. But buildroot is agnostic about what goes into the target device.

Ross: yocto has a curses UI, but there’s work on toaster, a web-GUI front end that tracks where things come from, e.g. this file in the target comes from that package.

Karim: build system is only command line, no GUI config. The UI on the target is in itself a compelling value proposition. Because Google controls it so heavily, it has consistency. So users already know how to use it.

Variety is good, because we can share

Ross: yes, we share patches for instance

Karim: the success of Android surprised even Google. But the straight-jacket of the framework has its limits.

Thomas: we’re building on the same components. For instance, we solve the cross-compilation issue, and when we make fixes we submit them upstream. It’s good for users (companies) to have the choice between build systems. Also we look at what other build systems are doing, and we consider if it would be useful to take over features. For instance, for buildroot it’s not useful to do package managers; if you need that, use yocto.

Tim: the worry is always about fragmentation of resources. Now, that’s not as big a concern because there is so much embedded system development. The great thing about diversity is that there are a lot of good idea. It would be good if some good ideas from Android would be pulled back in other build systems.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s