- Using IC manufacturer header files
Re: Using IC manufacturer header files
toggle quoted messageShow quoted text
From: Nashif, Anas [mailto:anas.nashif(a)intel.com]
Sent: Thursday, April 21, 2016 14:25
To: Maciek Borzecki <maciek.borzecki(a)gmail.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
Subject: Re: [devel] Re: Re: Using IC manufacturer header files
On 20 Apr 2016, at 16:10, Maciek Borzecki <maciek.borzecki(a)gmail.com>wrote:
change the structure of the SDK provided by a vendor, but the OS build
- I don't trust vendors to have a reasonable release managementAgreed, see point above. Sometimes there's legitimate reasons to
(more often than not they prove to have none)
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
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.
Yes, that was my argument in favor of removing dependencies or additional layers of source control and instead keeping the files inside the Zephyr source tree. It's not ideal, but it sounds better to me than the alternatives at this point.
Join email@example.com to automatically receive all group messages.