On 20 Apr 2016, at 16:10, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:
<snip>
- I don't trust vendors to have a reasonable release management (more often than not they prove to have none)
Agreed, see point above. Sometimes there's legitimate reasons to change the structure of the SDK provided by a vendor, but the OS build shouldn't be affected by it. Furthermore, relying on a particular version could potentially then introduce dependency hell into the Zephyr build for certain architectures, where some users would start to complain that the OS doesn't build for a particular IC because they have an older (or newer) IC vendor SDK than the one that Zephyr depends on.
I understand that it's nicer from user's perspective that the CPU support is integrated into the main codebase. I'm just not sure if it will be possible to maintain this state in the long run. Integrating code from a 3rd party into the main codebase means that we've officially made maintaining compatibility our problem. While, this is ok to do it with IP stack from contiki, it's just one 3rd party project after all, it will be hard with the multitude of CPUs out there.
I know it sounds crazy, but OpenEmbedded BSP layers are not that bad to work with after all. I can imagine that having similar BSP layers for Zephyr would not be that complicated. These 'layers', maintained by community or interested parties, could provide a curated hardware enablement or support libraries.
This sounds like the mBed approach. Whether you put the files in Zephyr main source tree or in some other Git repo you are still maintaining the files the same way, adding the file somewhere else will just create dependencies on external modules.
