Topics

Using IC manufacturer header files


Carles Cufi
 

Hi there,

We are working on a port to a new ARM SoC family (Nordic nRF5X) and are wondering about a couple of things.
There has been some discussion lately on whether to use the ARM CMSIS header files directly. After a short discussion with Ben, we decided to integrate them in our branch (include/arch/arm/cortex_m/cmsis-core) so as to use a standard API to interface with the Cortex-M cores.
But a new question arose when adding SoC-specific headers to the Zephyr codebase: Nordic provides an MDK with all the relevant header files describing registers, interrupts and memory map of the SoCs. Those are licensed under a 3-clause BSD and we could use them directly so as to follow the trend we started with CMSIS to reuse whatever the manufacturer provides. However there are some coding convention clashes (IRQs listed as an enum instead of #define statements, coding style, etc). So the decision to take now is whether to use the Nordic header files unchanged or to provide our own that more closely match the rest of the architectures in terms of organization and coding style.

Is there a recommended approach for this type of dilemma?

Thanks!

Carles


Nashif, Anas
 

Hi,
Any files or headers included from an external project that need to be kept in sync with upstream can keep their style and formatting to allow updates in the future. This was the approach taken when we imported the IP stack from contiki AFAIK.

Anas

On 19/04/2016, 04:55, "Cufi, Carles" <Carles.Cufi(a)nordicsemi.no> wrote:

Hi there,

We are working on a port to a new ARM SoC family (Nordic nRF5X) and are wondering about a couple of things.
There has been some discussion lately on whether to use the ARM CMSIS header files directly. After a short discussion with Ben, we decided to integrate them in our branch (include/arch/arm/cortex_m/cmsis-core) so as to use a standard API to interface with the Cortex-M cores.
But a new question arose when adding SoC-specific headers to the Zephyr codebase: Nordic provides an MDK with all the relevant header files describing registers, interrupts and memory map of the SoCs. Those are licensed under a 3-clause BSD and we could use them directly so as to follow the trend we started with CMSIS to reuse whatever the manufacturer provides. However there are some coding convention clashes (IRQs listed as an enum instead of #define statements, coding style, etc). So the decision to take now is whether to use the Nordic header files unchanged or to provide our own that more closely match the rest of the architectures in terms of organization and coding style.

Is there a recommended approach for this type of dilemma?

Thanks!

Carles


Maciek Borzecki <maciek.borzecki@...>
 

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:
Hi,
Any files or headers included from an external project that need to be kept in sync with upstream can keep their style and formatting to allow updates in the future. This was the approach taken when we imported the IP stack from contiki AFAIK.
How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Cheers,
--
Maciek Borzecki


Nashif, Anas
 

Hi,
Preference is to keep the most essential parts for building a basic Zephyr application on a specific board self-contained without external dependencies.

Anas

On 19/04/2016, 11:26, "Maciek Borzecki" <maciek.borzecki(a)gmail.com> wrote:

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:
Hi,
Any files or headers included from an external project that need to be kept in sync with upstream can keep their style and formatting to allow updates in the future. This was the approach taken when we imported the IP stack from contiki AFAIK.
How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Cheers,
--
Maciek Borzecki


Carles Cufi
 

Hi there,

-----Original Message-----
From: Nashif, Anas [mailto:anas.nashif(a)intel.com]
Sent: Tuesday, April 19, 2016 17:04
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Using IC manufacturer header files

Hi,
Any files or headers included from an external project that need to be
kept in sync with upstream can keep their style and formatting to allow
updates in the future. This was the approach taken when we imported the
IP stack from contiki AFAIK.
Sounds like a good idea. Since those files are part of the Nordic MDK, which sees frequent releases, I also think it would not make sense to try and convert them to a different coding style.

Thanks,

Carles


Carles Cufi
 

Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, April 19, 2016 17:27
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas <anas.nashif(a)intel.com>
wrote:
Hi,
Any files or headers included from an external project that need to be
kept in sync with upstream can keep their style and formatting to allow
updates in the future. This was the approach taken when we imported the
IP stack from contiki AFAIK.

How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Not sure if you mean pulling the source code from another repository at build time, since I don't know what buildroot does with kernel/toolchains.
However the MDK is not currently available in a repository, instead it is released as a .zip file by Nordic every time it gets updated. We could of course mirror it in a repo, but that would anyway require us to update it manually every time a new version is available.

Thanks,

Carles


Carles Cufi
 

Hi Anas,

-----Original Message-----
From: Nashif, Anas [mailto:anas.nashif(a)intel.com]
Sent: Tuesday, April 19, 2016 17:46
To: Maciek Borzecki <maciek.borzecki(a)gmail.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Using IC manufacturer header files

Hi,
Preference is to keep the most essential parts for building a basic
Zephyr application on a specific board self-contained without external
dependencies.
Sounds good. However please bear in mind that those are SoC include headers, not board ones. They define registers and memory maps for the different Nordic System-on-Chip.

Given the current feedback, we'll proceed to use the original header files directly and without modification by simply including them in the Zephyr codebase.

Thanks,

Carles


Maciek Borzecki <maciek.borzecki@...>
 

On Tue, Apr 19, 2016 at 10:50 PM, Cufi, Carles
<Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, April 19, 2016 17:27
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas <anas.nashif(a)intel.com>
wrote:
Hi,
Any files or headers included from an external project that need to be
kept in sync with upstream can keep their style and formatting to allow
updates in the future. This was the approach taken when we imported the
IP stack from contiki AFAIK.

How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Not sure if you mean pulling the source code from another repository at build time, since I don't know what buildroot does with kernel/toolchains.
However the MDK is not currently available in a repository, instead it is released as a .zip file by Nordic every time it gets updated. We could of course mirror it in a repo, but that would anyway require us to update it manually every time a new version is available.
What I meant is that you keep the {S,M}DK externally and just
configure a path to it inside Kconfig. You can add a config entry like
CONFIG_STM32F1_STDLIB_PATH. Then in project/driver makefiles
-I$(CONFIG_STM32F1_STDLIB_PATH) and optionally add some files to the
build as needed. This has one major advantage, that the 3rd party code
is kept outside of Zephyr repository, so you basically don't care
about the naming/conventions/licenses 3rd party libraries would use.

As for mirroring 3rd party SDK in a repo. No matter the vendor's
distribution method I always pull the source code into a git
repository for two main reasons:
- I don't trust vendors to have a reasonable release management (more
often than not they prove to have none)
- you cannot rely on developers putting/extracting SDK's at proper
locations and setting their dev environment

The multi repository projects can be easily remedied by using `repo`
tool or git submodules.

Cheers,
--
Maciek Borzecki


Carles Cufi
 

Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, April 20, 2016 19:24
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Nashif, Anas <anas.nashif(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 10:50 PM, Cufi, Carles
<Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, April 19, 2016 17:27
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas <anas.nashif(a)intel.com>
wrote:
Hi,
Any files or headers included from an external project that need to
be
kept in sync with upstream can keep their style and formatting to
allow updates in the future. This was the approach taken when we
imported the IP stack from contiki AFAIK.

How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Not sure if you mean pulling the source code from another repository
at build time, since I don't know what buildroot does with
kernel/toolchains.
However the MDK is not currently available in a repository, instead it
is released as a .zip file by Nordic every time it gets updated. We
could of course mirror it in a repo, but that would anyway require us to
update it manually every time a new version is available.

What I meant is that you keep the {S,M}DK externally and just configure
a path to it inside Kconfig. You can add a config entry like
CONFIG_STM32F1_STDLIB_PATH. Then in project/driver makefiles
-I$(CONFIG_STM32F1_STDLIB_PATH) and optionally add some files to the
build as needed. This has one major advantage, that the 3rd party code
is kept outside of Zephyr repository, so you basically don't care about
the naming/conventions/licenses 3rd party libraries would use.
I couldn't find the CONFIG_STM32F1_STDLIB_PATH you mentioned, and I tried to build the "hello_world" sample for STM32 and it worked fine, even though I have no STM SDK installed at all. With that I mean that it looks like, so far, archs are self-contained. The problem with the "-I$(NORDIC_MDK_PATH)" approach is that, as you mention later, Nordic might change the folder structure of the .zip file that it provides, rename some files and change it completely, leaving us at the mercy of the vendor.

As for mirroring 3rd party SDK in a repo. No matter the vendor's
distribution method I always pull the source code into a git repository
for two main reasons:
By pulling into the repo I assume you mean actually duplicating the files inside the target repo, instead of "pulling" them from an external repo.

- 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.

- you cannot rely on developers putting/extracting SDK's at proper
locations and setting their dev environment
Yes, this is especially troublesome in this case. The MDK is delivered as a .zip file for Linux and there is no installer or standardized path for it.


The multi repository projects can be easily remedied by using `repo`
tool or git submodules.
Although that is true, it would break the current seemingly desirable feature of the Zephyr codebase, and that is it being self-contained. Git submodules or repo add an additional layer of complexity to users, and that is not something I envision introducing at this point.

So far we have a nice, self-contained repo with a subset of (almost) untouched Nordic MDK files in the arch folder. We'll start with that and see how that works in the future.

Thanks,

Carles


Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Apr 20, 2016 at 9:28 PM, Cufi, Carles <Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, April 20, 2016 19:24
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Nashif, Anas <anas.nashif(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 10:50 PM, Cufi, Carles
<Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, April 19, 2016 17:27
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas <anas.nashif(a)intel.com>
wrote:
Hi,
Any files or headers included from an external project that need to
be
kept in sync with upstream can keep their style and formatting to
allow updates in the future. This was the approach taken when we
imported the IP stack from contiki AFAIK.

How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Not sure if you mean pulling the source code from another repository
at build time, since I don't know what buildroot does with
kernel/toolchains.
However the MDK is not currently available in a repository, instead it
is released as a .zip file by Nordic every time it gets updated. We
could of course mirror it in a repo, but that would anyway require us to
update it manually every time a new version is available.

What I meant is that you keep the {S,M}DK externally and just configure
a path to it inside Kconfig. You can add a config entry like
CONFIG_STM32F1_STDLIB_PATH. Then in project/driver makefiles
-I$(CONFIG_STM32F1_STDLIB_PATH) and optionally add some files to the
build as needed. This has one major advantage, that the 3rd party code
is kept outside of Zephyr repository, so you basically don't care about
the naming/conventions/licenses 3rd party libraries would use.
I couldn't find the CONFIG_STM32F1_STDLIB_PATH you mentioned, and I tried to build the "hello_world" sample for STM32 and it worked fine, even though I have no STM SDK installed at all.
Right, but only because the implementation was done in such way.
Frankly, if I used ST's libraries, it would have saved me a lot of
time during porting. Instead, I followed the example set by other,
already supported, targets and implemented STM32 specific pieces from
scratch by looking at the CPU manuals only.

With that I mean that it looks like, so far, archs are self-contained. The problem with the "-I$(NORDIC_MDK_PATH)" approach is that, as you mention later, Nordic might change the folder structure of the .zip file that it provides, rename some files and change it completely, leaving us at the mercy of the vendor.

As for mirroring 3rd party SDK in a repo. No matter the vendor's
distribution method I always pull the source code into a git repository
for two main reasons:
By pulling into the repo I assume you mean actually duplicating the files inside the target repo, instead of "pulling" them from an external repo.

- 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.


- you cannot rely on developers putting/extracting SDK's at proper
locations and setting their dev environment
Yes, this is especially troublesome in this case. The MDK is delivered as a .zip file for Linux and there is no installer or standardized path for it.


The multi repository projects can be easily remedied by using `repo`
tool or git submodules.
Although that is true, it would break the current seemingly desirable feature of the Zephyr codebase, and that is it being self-contained. Git submodules or repo add an additional layer of complexity to users, and that is not something I envision introducing at this point.

So far we have a nice, self-contained repo with a subset of (almost) untouched Nordic MDK files in the arch folder. We'll start with that and see how that works in the future.

Thanks,

Carles


--
Maciek Borzecki


Carles Cufi
 

Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, April 20, 2016 22:10
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Nashif, Anas <anas.nashif(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Wed, Apr 20, 2016 at 9:28 PM, Cufi, Carles
<Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, April 20, 2016 19:24
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Nashif, Anas <anas.nashif(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 10:50 PM, Cufi, Carles
<Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, April 19, 2016 17:27
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas
<anas.nashif(a)intel.com>
wrote:
Hi,
Any files or headers included from an external project that need
to be
kept in sync with upstream can keep their style and formatting to
allow updates in the future. This was the approach taken when we
imported the IP stack from contiki AFAIK.

How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Not sure if you mean pulling the source code from another
repository
at build time, since I don't know what buildroot does with
kernel/toolchains.
However the MDK is not currently available in a repository, instead
it
is released as a .zip file by Nordic every time it gets updated. We
could of course mirror it in a repo, but that would anyway require us
to update it manually every time a new version is available.

What I meant is that you keep the {S,M}DK externally and just
configure a path to it inside Kconfig. You can add a config entry
like CONFIG_STM32F1_STDLIB_PATH. Then in project/driver makefiles
-I$(CONFIG_STM32F1_STDLIB_PATH) and optionally add some files to the
build as needed. This has one major advantage, that the 3rd party
code is kept outside of Zephyr repository, so you basically don't
care about the naming/conventions/licenses 3rd party libraries would
use.

I couldn't find the CONFIG_STM32F1_STDLIB_PATH you mentioned, and I
tried to build the "hello_world" sample for STM32 and it worked fine,
even though I have no STM SDK installed at all.

Right, but only because the implementation was done in such way.
Frankly, if I used ST's libraries, it would have saved me a lot of time
during porting. Instead, I followed the example set by other, already
supported, targets and implemented STM32 specific pieces from scratch by
looking at the CPU manuals only.

With that I mean that it looks like, so far, archs are self-contained.
The problem with the "-I$(NORDIC_MDK_PATH)" approach is that, as you
mention later, Nordic might change the folder structure of the .zip file
that it provides, rename some files and change it completely, leaving us
at the mercy of the vendor.

As for mirroring 3rd party SDK in a repo. No matter the vendor's
distribution method I always pull the source code into a git
repository for two main reasons:
By pulling into the repo I assume you mean actually duplicating the
files inside the target repo, instead of "pulling" them from an external
repo.

- 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.
Well the only alternatives to directly integrating IC manufacturer header files into the Zephyr repo that I can conceive are:

1) Maintain the manufacturer files in a separate repository that we somehow (submodule or repo) pull into the build
2) Require the user to pre-install those header files as a dependency to be able to build for a particular architecture
3) Re-implement all the functionality provided by those IC manufacturer header files in our own style and inside the Zephyr repo

I personally dislike 1) and 2) for the reasons I've already exposed in previous emails, so for me the only real alternative is 3). But let's remember that we are talking about header files that describe SoCs here, not specific libraries a version of which we maintain internally. Those header files reflect the register set and the memory map of the SoC, and for that reason they tend to be accurate and well-tested since they have been used to develop the source examples that IC manufacturers already provide in their SDKs. That is yet another reason for me to advocate for the usage of these files unchanged and integrated in our repository. Furthermore, SoCs do not tend to change often (they are hardware descriptions after all) and therefore maintaining them internally should not be too onerous.


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 goes beyond the scope of the work we are trying to do here I believe. For now we want to add support for an architecture, and establishing a layer system for SoC support is not something we have contemplated so far.

Thanks,

Carles


Nashif, Anas
 

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.


Anas


Carles Cufi
 

Hi Anas,

-----Original Message-----
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>;
devel(a)lists.zephyrproject.org
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:

<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.

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.

Carles