OSTree as an output target for OE
...is something I'd love to see. I don't have much time in the immediate future to work on it myself, but I'd just like to raise the visibility of the project here because I am very much keeping in mind the needs of embedded systems. Or at least what I perceive them to be; my job is not embedded, even though I use OE for a project.
In particular I know that while historically many embedded devices aren't Internet connected, that's changing (which is a good and bad thing). But if your device will have the ability to upgrade itself online, OSTree offers a model for completely atomic upgrades, which I imagine is quite desirable for many unattended devices.
Here's a link to the LWN article:
http://lwn.net/Articles/564793/
Which links to my blog, but the most relevant thing here will probably be:
https://people.gnome.org/~walters/ostree/doc/
Many of the changes it asks for:
https://people.gnome.org/~walters/ostree/doc/adapting-existing.html
are somewhat nontrivial from the current OE-core; but on the other hand, it's not *that* far away.
The biggest technical change is having a new rootfs backend; I have a truly hideous, hacky implementation here:
https://github.com/cgwalters/poky/blob/gnomeostree-3.10-dylan/meta-gnomeos/classes/gnomeos-contents.bbclass
which includes doing UsrMove (and further, unifying bin/sbin) etc. which then generates two tarballs out of the OE content. From there, I take those two tarballs and commit it into an OSTree repository:
Then on the client side, users can choose between the refs "gnome-ostree/buildmaster/x86_64-runtime" and "gnome-ostree/buildmaster/x86_64-devel-debug" where the first is a runtime system with no debuginfo, and -devel-debug has all of the developer tools (gcc, make, etc.) and *all* of the debuginfo.
So you can see here the client machine can (relatively efficiently) switch trees; it's not like images where you are locked into one thing. It's also not like packages where you have a combinatorial explosion of options.