...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: https://git.gnome.org/browse/gnome-ostree/tree/src/js/tasks/task-build.js?id=600ea8e70cf8c8bf56a79ad5ec39c122f9066a92#n1125 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. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
