| Message ID | 20170201131409.26631-1-mike.holmes@linaro.org |
|---|---|
| Headers | show |
| Series | Add ABI compatibility to helper lib | expand |
> -----Original Message----- > From: lng-odp [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of Mike > Holmes > Sent: Wednesday, February 01, 2017 3:14 PM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [PATCH 0/5] Add ABI compatibility to helper lib > > Reusing the mechanism used for the ODP API, allow the helpers to build in > ABI > mode where they optionally do not use static inline in the header file. Helpers themselves can be inline code. There are no issues if helpers are built with the same ODP configuration (ABI_COMPAT) and CC flags as the rest of the application. If you handle helper code as part of application code (as it should be), helper code will be ABI_COMPAT when the application using it is ABI_COMPAT itself. Simplest solution would be to include helpers into application makefile instead of building a helper lib. If helper lib is a must, then the second simplest solution is to build that with the implementation lib. Helper lib is ABI_COMPAT when implementation lib is ABI_COMPAT, and an ABI_COMPAT application must include both of those ABI combat libs. There should be only one copy of helper source code, implementation will not modify it but just build it. Similarly to application files, helper files should not need to know if it's built against ABI_COMPAT or not. There should not be "#if ABI_COMPAT" in any of the helper files. ABI spec should be visible only on implementation side - which headers (types/values/inlines) are included through ODP API files. -Petri
On 2 February 2017 at 02:59, Savolainen, Petri (Nokia - FI/Espoo) <petri. savolainen@nokia-bell-labs.com> wrote: > > > > -----Original Message----- > > From: lng-odp [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of > Mike > > Holmes > > Sent: Wednesday, February 01, 2017 3:14 PM > > To: lng-odp@lists.linaro.org > > Subject: [lng-odp] [PATCH 0/5] Add ABI compatibility to helper lib > > > > Reusing the mechanism used for the ODP API, allow the helpers to build in > > ABI > > mode where they optionally do not use static inline in the header file. > > > Helpers themselves can be inline code. > > There are no issues if helpers are built with the same ODP configuration > (ABI_COMPAT) and CC flags as the rest of the application. If you handle > helper code as part of application code (as it should be), helper code will > be ABI_COMPAT when the application using it is ABI_COMPAT itself. > > Simplest solution would be to include helpers into application makefile > instead of building a helper lib. If helper lib is a must, then the second > simplest solution is to build that with the implementation lib. It can't be built into the odp implementation lib, why would we force all implementations to carry copies of unchanging code such as the tables, OS specifics etc. We need to pull out code that is needed but not possible to HW accelerate, it should not be in the ODP lib, that lib is HW accelerated implementations of the ODP API. > Helper lib is ABI_COMPAT when implementation lib is ABI_COMPAT, and an > ABI_COMPAT application must include both of those ABI combat libs. There > should be only one copy of helper source code, implementation will not > modify it but just build it. Agree about one copy and I would add that the implementation should not even need to build it, it should already be in the distro for that arch in a cloudy case. > > Similarly to application files, helper files should not need to know if > it's built against ABI_COMPAT or not. There should not be "#if ABI_COMPAT" > in any of the helper files. ABI spec should be visible only on > implementation side - which headers (types/values/inlines) are included > through ODP API files. > Agree, application should not know, I am not sure why it would need to, by default it uses the installed helper arch lib. If you choose to you compile something more specific, presumably because the helper you call is known to be calling an inline of the ODP API, but that is your choice because you have the knowledge and are prepared to limit your portability. > > -Petri > > -- Mike Holmes Program Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs "Work should be fun and collaborative, the rest follows"
From: Mike Holmes [mailto:mike.holmes@linaro.org] Sent: Thursday, February 02, 2017 2:39 PM To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com> Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] [PATCH 0/5] Add ABI compatibility to helper lib On 2 February 2017 at 02:59, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com> wrote: > -----Original Message----- > From: lng-odp [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of Mike > Holmes > Sent: Wednesday, February 01, 2017 3:14 PM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [PATCH 0/5] Add ABI compatibility to helper lib > > Reusing the mechanism used for the ODP API, allow the helpers to build in > ABI > mode where they optionally do not use static inline in the header file. Helpers themselves can be inline code. There are no issues if helpers are built with the same ODP configuration (ABI_COMPAT) and CC flags as the rest of the application. If you handle helper code as part of application code (as it should be), helper code will be ABI_COMPAT when the application using it is ABI_COMPAT itself. Simplest solution would be to include helpers into application makefile instead of building a helper lib. If helper lib is a must, then the second simplest solution is to build that with the implementation lib. It can't be built into the odp implementation lib, why would we force all implementations to carry copies of unchanging code such as the tables, OS specifics etc. We need to pull out code that is needed but not possible to HW accelerate, it should not be in the ODP lib, that lib is HW accelerated implementations of the ODP API. >>>> Not into implementation lib, but _with_ the implementation lib - using the same flags, storing it with the same naming convention, etc. For example: odp-linux-abi-x86_64.a, odp-helper-abi-x86_64.a, ... Helper lib is ABI_COMPAT when implementation lib is ABI_COMPAT, and an ABI_COMPAT application must include both of those ABI combat libs. There should be only one copy of helper source code, implementation will not modify it but just build it. Agree about one copy and I would add that the implementation should not even need to build it, it should already be in the distro for that arch in a cloudy case. >>>> If a distro pulls in odp-linux, it needs to be build into a lib at some point of time. If the helper lib is built simultaneously with the odp-linux lib, no additional helper ABI flags are needed (helper lib build inherit odp-linux lib build flags). -Petri BTW. The current helper/platform/linux-generic/thread_extn.h stuff is very messy on application (OFP) side. I'll send a patch where linux helpers are again linux helpers and not "linux-generic" helpers. Similarly to application files, helper files should not need to know if it's built against ABI_COMPAT or not. There should not be "#if ABI_COMPAT" in any of the helper files. ABI spec should be visible only on implementation side - which headers (types/values/inlines) are included through ODP API files. Agree, application should not know, I am not sure why it would need to, by default it uses the installed helper arch lib. If you choose to you compile something more specific, presumably because the helper you call is known to be calling an inline of the ODP API, but that is your choice because you have the knowledge and are prepared to limit your portability. -Petri -- Mike Holmes Program Manager - Linaro Networking Group Linaro.org │ Open source software for ARM SoCs "Work should be fun and collaborative, the rest follows"