If the ODP prototypes simply all said 'static inline' then would that permit the implementation to choose later which were actually static inline?
I.e., if the common odp_xxx.h says static inline void *odp_foo(...); Then can the implementation can say; static inline void *odp_foo(...) { }; to make the function inline and just say void *odp_foo(...) { }; to make it an actual call? On Tue, Nov 4, 2014 at 11:32 AM, Bill Fischofer <bill.fischo...@linaro.org> wrote: > It's unfortunate that C (and GCC) have these inlining limitations. This, > BTW, is exactly the sort of thing that LLVM was designed to handle--and > without requiring the programmer to decide in advance which functions > should and should not be inlined. > > We could wrapper the independent APIs in macros that the platforms could > override to determine which prototypes should be marked 'static inline'. > Would that work? > > On Tue, Nov 4, 2014 at 11:27 AM, Taras Kondratiuk < > taras.kondrat...@linaro.org> wrote: > >> On 11/04/2014 04:29 PM, Ciprian Barbu wrote: >> >>> Here is a first attempt to remove inlines from API files. I also moved >>> some >>> defines and typedefs out of some of the API headers. There is still room >>> for >>> improvement I guess, the inline implementation and defines could be >>> split into >>> their own files, but I just tried to show the general idea. >>> >>> I also tried to make the documentation look good, the platform inlines >>> reference >>> the documentation in the corresponding API file. >>> >>> I removed almost all of the individual API includes from C files, >>> keeping only >>> odp.h, which I remember was desirable. This can still be discussed. >>> >>> --- >>> example/ipsec/odp_ipsec.c | 2 - >>> example/ipsec/odp_ipsec_cache.c | 2 - >>> example/ipsec/odp_ipsec_fwd_db.c | 1 - >>> example/ipsec/odp_ipsec_loop_db.c | 2 - >>> example/ipsec/odp_ipsec_sa_db.c | 2 - >>> example/ipsec/odp_ipsec_sp_db.c | 2 - >>> example/ipsec/odp_ipsec_stream.c | 3 - >>> helper/include/odph_eth.h | 4 - >>> helper/include/odph_icmp.h | 3 - >>> helper/include/odph_ip.h | 3 - >>> helper/include/odph_ipsec.h | 4 - >>> helper/include/odph_udp.h | 3 - >>> platform/linux-generic/include/api/odp.h | 6 + >>> platform/linux-generic/include/api/odp_atomic.h | 282 ++++------- >>> platform/linux-generic/include/api/odp_byteorder.h | 187 ++------ >>> platform/linux-generic/include/api/odp_coremask.h | 47 +- >>> .../include/api/odp_platform_defines.h | 152 ++++++ >>> .../include/api/odp_platform_inlines.h | 527 >>> +++++++++++++++++++++ >>> platform/linux-generic/include/api/odp_version.h | 44 +- >>> platform/linux-generic/odp_barrier.c | 3 +- >>> platform/linux-generic/odp_buffer.c | 2 +- >>> platform/linux-generic/odp_buffer_pool.c | 8 +- >>> platform/linux-generic/odp_coremask.c | 3 +- >>> platform/linux-generic/odp_crypto.c | 9 +- >>> platform/linux-generic/odp_packet.c | 4 +- >>> platform/linux-generic/odp_packet_flags.c | 2 +- >>> platform/linux-generic/odp_packet_io.c | 11 +- >>> platform/linux-generic/odp_packet_socket.c | 2 +- >>> platform/linux-generic/odp_queue.c | 10 +- >>> platform/linux-generic/odp_ring.c | 6 +- >>> platform/linux-generic/odp_rwlock.c | 3 +- >>> platform/linux-generic/odp_schedule.c | 11 +- >>> platform/linux-generic/odp_thread.c | 7 +- >>> platform/linux-generic/odp_ticketlock.c | 4 +- >>> platform/linux-generic/odp_timer.c | 7 +- >>> 35 files changed, 849 insertions(+), 519 deletions(-) >>> create mode 100644 platform/linux-generic/include/api/odp_platform_ >>> defines.h >>> create mode 100644 platform/linux-generic/include/api/odp_platform_ >>> inlines.h >>> >> >> Having all 'inlines' in one file isn't a good idea. I assume most of >> fast path APIs will be there as wrappers to vendor's SDK. >> This approach will also face the same issues I've faced in my previous >> try. >> >> Current ODP headers contains following parts in each file: >> >> 1. Platform-specific >> 1.a. Handle typedefs: e.g. odp_queue_t >> 1.b. Macros, enums: e.g. ODP_SCHED_PRIO_NORMAL >> >> 2. Platform-independent >> 2.a. Data structures, typedefs: e.g. odp_queue_param_t >> 2.b. Function prototypes: e.g. odp_queue_create() >> >> Splitting them into platform-specific and platform-independent >> parts looks straight forward until one wants to implement some API as >> inline but that API needs a platform-independent typedef (2.a). >> According to current C standards 'static inline' implementation must be >> ahead of its prototype if prototype doesn't have 'static inline'. This >> is our case. >> If (2.a) and (2.b) bundled together, then there is no way for >> implementation to get only typedef (2.a), implement function and then >> include API prototype (2.b) to pull-in documentation and verification >> of the function prototype. >> >> For now I see two ways to solve it: >> 1. ODP provides (2.a) and (2.b) as two separate include files, so >> implementation can use them as it wish. E.g. odp_queue_struct.h and >> odp_queue_func.h >> 2. (2.a) and (2.b) are in the same file, but there is a platform include >> hook between them. Similarly to plat/odp_*.h approach in my last >> series on this topic. >> >> Unfortunately both approaches has its own pros and cons. >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/lng-odp >> > >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp