1 Reply Latest reply on Apr 8, 2015 7:58 AM by JPMontero_Intel

    Edison Yocto layer modularity


      I should probably preface this by saying that all of my Linux boxes (except the one I use to cross-compile for Edison) run Gentoo.


      Lately I've been working with the Edison Yocto image, trying to get a handle on what's there, and what I will need for my project - a mix of robotics and eventually image processing.


      For an embedded device, I guess I'm a little curious about the overall packaging.  There is a grand total of 4 GB of storage on the device, and the default image seems to take an "everything, including the kitchen sink" approach to the OS.


      It seems like a good approach for a product looking for a market - but the organization feels like it's lacking.  I feel like no one will be using all of the features that are presented in the default image.  There's something for everyone, but at the same time, everyone (who looks hard enough) will find things they wish they could trade for space on the device.


      So, a (very) modular approach would seem to lend itself to this design.  Yocto seems to be quite modular, conceptually, but the Edison layers are less so, from a developer-user's perspective.


      In a modular approach, I would think, the distribution edison-image would have almost no occurrences of "IMAGE_INSTAL += ..." for individual packages.  There should be a layer and a corresponding image that defines a barely bootable setup, complete with a kernel configuration.  Things like multimedia that aren't necessary to boot, but require kernel support should be in a separate layer with a kernel configuration patch.  Platform "features" like Node.js, Arduino support, the IoT kit, and MRAA and UPM should be in separate package groups, contained in one or more layers.


      Then, someone wanting to create a custom image could just create a new layer and include/require packages and packagegroups that are defined in the distribution layers.  That seems like what the Yocto documentation is driving at.


      As it stands, to create an image that is substantially different from edison-image, the best route seems to be to copy and modify edison-image.bb into a different layer, then find the pieces in the various edison-image.bbappend's, and then deal with some assumptions in the postBuild and flashall scripts about some filenames.


      By the way, in the process of creating my custom image, I found that the oobe recipe is missing an RDEPENDS on mdns.  Also, it would be nice if it (OOBE) wasn't dependent on Node.js (my minimalistic tendencies have their limits, apparently).