Re: [lng-odp] [PATCH 0/8] First ABI files

[Bill Fischofer]

On Fri, Jan 20, 2017 at 8:22 AM, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia-bell-labs.com> wrote:
>
>
>> -Original Message-
>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> Sent: Friday, January 20, 2017 4:13 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
>> labs.com>
>> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
>> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>>
>> On Fri, Jan 20, 2017 at 3:33 AM, Savolainen, Petri (Nokia - FI/Espoo)
>> <petri.savolai...@nokia-bell-labs.com> wrote:
>> >> -Original Message-
>> >> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> >> Sent: Thursday, January 19, 2017 11:53 PM
>> >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
>> >> labs.com>
>> >> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
>> >> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>> >>
>> >> This series represents a significant structural change and as such
>> >> should go against api-next, not master. Patches aimed at master should
>> >> be bug fixes, not something that introduces new structure development.
>> >
>> >
>> > I think we should stop right here of doing "significant changes" through
>> api-next. Last time that policy effectively stopped the work in master due
>> to dependencies over many files changed. Api-next should be reserved only
>> for API spec changing modifications, since only those are visible to
>> applications. E.g. changes in ABI does not require any application change.
>> Today our "ABI" support is non-existent. This sets ground work for files
>> and Makefiles to enable ABI(s) and force that.
>> >
>> >
>> >>
>> >> While the goals here seem good, I'm concerned that at this stage
>> >> applying this removes strong typing support. For example, as an
>> >> experiment I changed the buffer validation test to contain this error:
>> >
>> > I'll look into strong typing as default. But vendors may very well agree
>> not to support it, since it requires handles to be pointer size types.
>> E.g. arm64 ABI may be agreed to use uint32_t for handles instead of
>> pointers.
>> >
>>
>> Are there many storage-constrained 64-bit systems? For 32-bit embedded
>> environments pointers are already 4 bytes, so this shouldn't be a
>> problem. Since handles are opaque, the only thing that's needed for
>> ABI compatibility is that there is common agreement on their size
>> since application code never manipulates the structure of any
>> handle--that's all done in each implementation.
>>
>> This is another reason to have internal vs. external handles as we
>> discussed earlier with Honnappa. The strong typing is most important
>> on the external handles since they are part of the API spec even if
>> the details are left to each implementation. Implementations can
>> choose to relax this if they want more compact handles for internal
>> use.
>
> The excessive storage size is the main issue here. E.g. if all handles are 8 
> bytes instead of 4 bytes, an application need to reserve 2x memory for the 
> same number of those. With double memory space both total memory consumption 
> may increase too high and more likely performance is lower due to less 
> handles fitting various cache levels.
>
> Also not all handles need to be 8 bytes of space. E.g. packet seg handle can 
> be a small integer since those are few and those depend on a packet handle, 
> etc.

I agree, however it's a deficiency in the C type system that there
doesn't appear to be any other way to achieve strong typing than the
one we settled on. A native C++ ODP API would have more options since
types in C++ are strong by default. There's also the question of C
language level. At the time we started this project it was felt that
C11 was "too new" to require, which is why we settled on C99. If it's
OK to reconsider C11 we might be able to improve on the current
techniques. Something to discuss?

>
> -Petri
>
>

Re: [lng-odp] [PATCH 0/8] First ABI files

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> Sent: Friday, January 20, 2017 4:13 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> labs.com>
> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
> 
> On Fri, Jan 20, 2017 at 3:33 AM, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia-bell-labs.com> wrote:
> >> -Original Message-
> >> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> >> Sent: Thursday, January 19, 2017 11:53 PM
> >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> >> labs.com>
> >> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
> >> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
> >>
> >> This series represents a significant structural change and as such
> >> should go against api-next, not master. Patches aimed at master should
> >> be bug fixes, not something that introduces new structure development.
> >
> >
> > I think we should stop right here of doing "significant changes" through
> api-next. Last time that policy effectively stopped the work in master due
> to dependencies over many files changed. Api-next should be reserved only
> for API spec changing modifications, since only those are visible to
> applications. E.g. changes in ABI does not require any application change.
> Today our "ABI" support is non-existent. This sets ground work for files
> and Makefiles to enable ABI(s) and force that.
> >
> >
> >>
> >> While the goals here seem good, I'm concerned that at this stage
> >> applying this removes strong typing support. For example, as an
> >> experiment I changed the buffer validation test to contain this error:
> >
> > I'll look into strong typing as default. But vendors may very well agree
> not to support it, since it requires handles to be pointer size types.
> E.g. arm64 ABI may be agreed to use uint32_t for handles instead of
> pointers.
> >
> 
> Are there many storage-constrained 64-bit systems? For 32-bit embedded
> environments pointers are already 4 bytes, so this shouldn't be a
> problem. Since handles are opaque, the only thing that's needed for
> ABI compatibility is that there is common agreement on their size
> since application code never manipulates the structure of any
> handle--that's all done in each implementation.
> 
> This is another reason to have internal vs. external handles as we
> discussed earlier with Honnappa. The strong typing is most important
> on the external handles since they are part of the API spec even if
> the details are left to each implementation. Implementations can
> choose to relax this if they want more compact handles for internal
> use.

The excessive storage size is the main issue here. E.g. if all handles are 8 
bytes instead of 4 bytes, an application need to reserve 2x memory for the same 
number of those. With double memory space both total memory consumption may 
increase too high and more likely performance is lower due to less handles 
fitting various cache levels.
 
Also not all handles need to be 8 bytes of space. E.g. packet seg handle can be 
a small integer since those are few and those depend on a packet handle, etc.

-Petri

Re: [lng-odp] [PATCH 0/8] First ABI files

[Bill Fischofer]

On Fri, Jan 20, 2017 at 3:33 AM, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia-bell-labs.com> wrote:
>> -Original Message-
>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> Sent: Thursday, January 19, 2017 11:53 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
>> labs.com>
>> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
>> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>>
>> This series represents a significant structural change and as such
>> should go against api-next, not master. Patches aimed at master should
>> be bug fixes, not something that introduces new structure development.
>
>
> I think we should stop right here of doing "significant changes" through 
> api-next. Last time that policy effectively stopped the work in master due to 
> dependencies over many files changed. Api-next should be reserved only for 
> API spec changing modifications, since only those are visible to 
> applications. E.g. changes in ABI does not require any application change. 
> Today our "ABI" support is non-existent. This sets ground work for files and 
> Makefiles to enable ABI(s) and force that.
>
>
>>
>> While the goals here seem good, I'm concerned that at this stage
>> applying this removes strong typing support. For example, as an
>> experiment I changed the buffer validation test to contain this error:
>
> I'll look into strong typing as default. But vendors may very well agree not 
> to support it, since it requires handles to be pointer size types. E.g. arm64 
> ABI may be agreed to use uint32_t for handles instead of pointers.
>

Are there many storage-constrained 64-bit systems? For 32-bit embedded
environments pointers are already 4 bytes, so this shouldn't be a
problem. Since handles are opaque, the only thing that's needed for
ABI compatibility is that there is common agreement on their size
since application code never manipulates the structure of any
handle--that's all done in each implementation.

This is another reason to have internal vs. external handles as we
discussed earlier with Honnappa. The strong typing is most important
on the external handles since they are part of the API spec even if
the details are left to each implementation. Implementations can
choose to relax this if they want more compact handles for internal
use.

> -Petri

Re: [lng-odp] [PATCH 0/8] First ABI files

[Savolainen, Petri (Nokia - FI/Espoo)]

> > I think we should stop right here of doing "significant changes" through
> api-next. Last time that policy effectively stopped the work in master due
> to dependencies over many files changed. Api-next should be reserved only
> for API spec changing modifications, since only those are visible to
> applications. E.g. changes in ABI does not require any application change.
> Today our "ABI" support is non-existent. This sets ground work for files
> and Makefiles to enable ABI(s) and force that.
> 
> I would argue that we should use branches, the problem was not
> api-next IMHO, but rather we had major changes from multiple
> contributors that collided in that one location. We ended up halting
> all work in api-next whilst the underpinning work was completed, not a
> criticism as such but the same would happen to any single repository
> bottle neck. I think we need to develop on parallel branches and then
> when they are ready they are just merged.
> 
> I could see two important maintainer branches in parallel to master.
> api-next owned by you
> driver owned by  Christophe
> 
> 
> When either of these major work area branches (on your own public
> repo) is ready you just send maxim a pull request and he can be sure
> the branch owners have already attained the required reviews etc.
> 
> Releases are super simple now, all pre tested and reviewed ready to
> go, merge and tag, it also scales to any amount of parallel
> conflicting work.

Mails in plain text, please.

When two developers touch the same lines on the same files, you cannot avoid a 
rebase. Multiple public branches would not make it better but worse, since a 
third/fourth/etc developer would not know which branch is "the latest" / 
official code base (== where to send a bug fix for example). Master should be 
always the branch that most people use and develop on. People that do not want 
to use the latest development, can choose a tagged version of master and stick 
with that (until the next tag).

For example, this ABI work will (eventually) modify all internal xxx_types.h 
files. If / when somebody else will do any modification on those same files, 
there will be a merge conflict.

If we all patch master and merge often, delta (and rebase effort) keeps small. 
Simultaneous, overlapping development on multiple branches (master / api-next / 
driver / xxx)  would just collect a huge rebase or  merge conflict debt that 
nobody wants to solve on the next release point. 

-Petri

Re: [lng-odp] [PATCH 0/8] First ABI files

[Bill Fischofer]

On Fri, Jan 20, 2017 at 7:22 AM, Mike Holmes <mike.hol...@linaro.org> wrote:
> Note, "driver" would stage though next for CI to look at it just as
> api-next does.
>
> On 20 January 2017 at 08:08, Mike Holmes <mike.hol...@linaro.org> wrote:
>> On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo)
>> <petri.savolai...@nokia-bell-labs.com> wrote:
>>>> -Original Message-
>>>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>>>> Sent: Thursday, January 19, 2017 11:53 PM
>>>> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
>>>> labs.com>
>>>> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
>>>> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>>>>
>>>> This series represents a significant structural change and as such
>>>> should go against api-next, not master. Patches aimed at master should
>>>> be bug fixes, not something that introduces new structure development.
>>>
>>>
>>> I think we should stop right here of doing "significant changes" through 
>>> api-next. Last time that policy effectively stopped the work in master due 
>>> to dependencies over many files changed. Api-next should be reserved only 
>>> for API spec changing modifications, since only those are visible to 
>>> applications. E.g. changes in ABI does not require any application change. 
>>> Today our "ABI" support is non-existent. This sets ground work for files 
>>> and Makefiles to enable ABI(s) and force that.
>>
>> I would argue that we should use branches, the problem was not
>> api-next IMHO, but rather we had major changes from multiple
>> contributors that collided in that one location. We ended up halting
>> all work in api-next whilst the underpinning work was completed, not a
>> criticism as such but the same would happen to any single repository
>> bottle neck. I think we need to develop on parallel branches and then
>> when they are ready they are just merged.
>>
>> I could see two important maintainer branches in parallel to master.
>> api-next owned by you
>> driver owned by  Christophe
>>
>>
>> When either of these major work area branches (on your own public
>> repo) is ready you just send maxim a pull request and he can be sure
>> the branch owners have already attained the required reviews etc.
>>
>> Releases are super simple now, all pre tested and reviewed ready to
>> go, merge and tag, it also scales to any amount of parallel
>> conflicting work.
>>

+1 for the development branch approach. I think we've reached the
level of maturity in the project where that technique should be the
default for any larger changes.

>>>
>>>
>>>>
>>>> While the goals here seem good, I'm concerned that at this stage
>>>> applying this removes strong typing support. For example, as an
>>>> experiment I changed the buffer validation test to contain this error:
>>>
>>> I'll look into strong typing as default. But vendors may very well agree 
>>> not to support it, since it requires handles to be pointer size types. E.g. 
>>> arm64 ABI may be agreed to use uint32_t for handles instead of pointers.
>>>
>>> -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"
>
>
>
> --
> Mike Holmes
> Program Manager - Linaro Networking Group
> Linaro.org │ Open source software for ARM SoCs
> "Work should be fun and collaborative, the rest follows"

Re: [lng-odp] [PATCH 0/8] First ABI files

[Mike Holmes]

Note, "driver" would stage though next for CI to look at it just as
api-next does.

On 20 January 2017 at 08:08, Mike Holmes <mike.hol...@linaro.org> wrote:
> On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia-bell-labs.com> wrote:
>>> -Original Message-
>>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>>> Sent: Thursday, January 19, 2017 11:53 PM
>>> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
>>> labs.com>
>>> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
>>> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>>>
>>> This series represents a significant structural change and as such
>>> should go against api-next, not master. Patches aimed at master should
>>> be bug fixes, not something that introduces new structure development.
>>
>>
>> I think we should stop right here of doing "significant changes" through 
>> api-next. Last time that policy effectively stopped the work in master due 
>> to dependencies over many files changed. Api-next should be reserved only 
>> for API spec changing modifications, since only those are visible to 
>> applications. E.g. changes in ABI does not require any application change. 
>> Today our "ABI" support is non-existent. This sets ground work for files and 
>> Makefiles to enable ABI(s) and force that.
>
> I would argue that we should use branches, the problem was not
> api-next IMHO, but rather we had major changes from multiple
> contributors that collided in that one location. We ended up halting
> all work in api-next whilst the underpinning work was completed, not a
> criticism as such but the same would happen to any single repository
> bottle neck. I think we need to develop on parallel branches and then
> when they are ready they are just merged.
>
> I could see two important maintainer branches in parallel to master.
> api-next owned by you
> driver owned by  Christophe
>
>
> When either of these major work area branches (on your own public
> repo) is ready you just send maxim a pull request and he can be sure
> the branch owners have already attained the required reviews etc.
>
> Releases are super simple now, all pre tested and reviewed ready to
> go, merge and tag, it also scales to any amount of parallel
> conflicting work.
>
>>
>>
>>>
>>> While the goals here seem good, I'm concerned that at this stage
>>> applying this removes strong typing support. For example, as an
>>> experiment I changed the buffer validation test to contain this error:
>>
>> I'll look into strong typing as default. But vendors may very well agree not 
>> to support it, since it requires handles to be pointer size types. E.g. 
>> arm64 ABI may be agreed to use uint32_t for handles instead of pointers.
>>
>> -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"



-- 
Mike Holmes
Program Manager - Linaro Networking Group
Linaro.org │ Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"

Re: [lng-odp] [PATCH 0/8] First ABI files

[Mike Holmes]

On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia-bell-labs.com> wrote:
>> -Original Message-
>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> Sent: Thursday, January 19, 2017 11:53 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
>> labs.com>
>> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
>> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>>
>> This series represents a significant structural change and as such
>> should go against api-next, not master. Patches aimed at master should
>> be bug fixes, not something that introduces new structure development.
>
>
> I think we should stop right here of doing "significant changes" through 
> api-next. Last time that policy effectively stopped the work in master due to 
> dependencies over many files changed. Api-next should be reserved only for 
> API spec changing modifications, since only those are visible to 
> applications. E.g. changes in ABI does not require any application change. 
> Today our "ABI" support is non-existent. This sets ground work for files and 
> Makefiles to enable ABI(s) and force that.

I would argue that we should use branches, the problem was not
api-next IMHO, but rather we had major changes from multiple
contributors that collided in that one location. We ended up halting
all work in api-next whilst the underpinning work was completed, not a
criticism as such but the same would happen to any single repository
bottle neck. I think we need to develop on parallel branches and then
when they are ready they are just merged.

I could see two important maintainer branches in parallel to master.
api-next owned by you
driver owned by  Christophe


When either of these major work area branches (on your own public
repo) is ready you just send maxim a pull request and he can be sure
the branch owners have already attained the required reviews etc.

Releases are super simple now, all pre tested and reviewed ready to
go, merge and tag, it also scales to any amount of parallel
conflicting work.

>
>
>>
>> While the goals here seem good, I'm concerned that at this stage
>> applying this removes strong typing support. For example, as an
>> experiment I changed the buffer validation test to contain this error:
>
> I'll look into strong typing as default. But vendors may very well agree not 
> to support it, since it requires handles to be pointer size types. E.g. arm64 
> ABI may be agreed to use uint32_t for handles instead of pointers.
>
> -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"

Re: [lng-odp] [PATCH 0/8] First ABI files

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> Sent: Thursday, January 19, 2017 11:53 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> labs.com>
> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
> 
> This series represents a significant structural change and as such
> should go against api-next, not master. Patches aimed at master should
> be bug fixes, not something that introduces new structure development.


I think we should stop right here of doing "significant changes" through 
api-next. Last time that policy effectively stopped the work in master due to 
dependencies over many files changed. Api-next should be reserved only for API 
spec changing modifications, since only those are visible to applications. E.g. 
changes in ABI does not require any application change. Today our "ABI" support 
is non-existent. This sets ground work for files and Makefiles to enable ABI(s) 
and force that. 


> 
> While the goals here seem good, I'm concerned that at this stage
> applying this removes strong typing support. For example, as an
> experiment I changed the buffer validation test to contain this error:

I'll look into strong typing as default. But vendors may very well agree not to 
support it, since it requires handles to be pointer size types. E.g. arm64 ABI 
may be agreed to use uint32_t for handles instead of pointers.

-Petri

Re: [lng-odp] [PATCH 0/8] First ABI files

[Bill Fischofer]

This series represents a significant structural change and as such
should go against api-next, not master. Patches aimed at master should
be bug fixes, not something that introduces new structure development.

While the goals here seem good, I'm concerned that at this stage
applying this removes strong typing support. For example, as an
experiment I changed the buffer validation test to contain this error:

void buffer_test_pool_alloc(void)
{
odp_packet_t pool;  <== Trying to use a packet as a pool here, should
be flagged by the compiler
const int num = 3;
odp_buffer_t buffer[num];
odp_event_t ev;
int index;
char wrong_type = 0, wrong_size = 0, wrong_align = 0;
odp_pool_param_t params;

odp_pool_param_init();
params.type  = ODP_POOL_BUFFER;
params.buf.size  = BUF_SIZE;
params.buf.align = BUF_ALIGN;
params.buf.num   = num;

pool = odp_pool_create("buffer_pool_alloc", );

and this now compiles fine without complaint. That's a serious
functional regression that we really don't want. As I mentioned during
the ARCH call, we should promote strong typing into these ABI
structures so that they carry over to other platforms the reuse them,
or at minimum ensure that the odp-linux instantiations of these
structures retain strong typing support.


On Thu, Jan 19, 2017 at 2:13 AM, Petri Savolainen
 wrote:
> Added initial version of couple of ABI specification files. These files define
> types/values that are implementation specific in the API spec. For ABI
> compatibility, application and implementation need to use these definitions
> (based on the target architecture). ABI is defined by CPU ISA (including
> version, endianism, etc) and SW environment (OS and compiler). Six different
> ABIs are initially defined - all are Linux based and assume the default
> endianism.
>
> Some unused types were found for API spec. Those will be removed once this
> patch set is merged with api-next.
>
>
> Petri Savolainen (8):
>   abi: event: added the first ABI spec file
>   abi: buffer: added initial definitions
>   abi: classifier: added initial definitions
>   abi: crypto: added initial definitions
>   abi: packet: added initial definitions
>   abi: pool: added initial definitions
>   abi: queue: added initial definitions
>   abi: shm: added initial definitions
>
>  configure.ac   | 22 +++
>  example/Makefile.inc   |  1 +
>  example/timer/odp_timer_test.c |  2 +-
>  helper/Makefile.am |  1 +
>  include/odp/arch/arm32-linux/odp/api/abi/buffer.h  |  7 
>  .../arch/arm32-linux/odp/api/abi/classification.h  |  7 
>  include/odp/arch/arm32-linux/odp/api/abi/crypto.h  |  7 
>  include/odp/arch/arm32-linux/odp/api/abi/event.h   |  7 
>  include/odp/arch/arm32-linux/odp/api/abi/packet.h  |  7 
>  include/odp/arch/arm32-linux/odp/api/abi/pool.h|  7 
>  include/odp/arch/arm32-linux/odp/api/abi/queue.h   |  7 
>  .../arch/arm32-linux/odp/api/abi/shared_memory.h   |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/buffer.h  |  7 
>  .../arch/arm64-linux/odp/api/abi/classification.h  |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/crypto.h  |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/event.h   |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/packet.h  |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/pool.h|  7 
>  include/odp/arch/arm64-linux/odp/api/abi/queue.h   |  7 
>  .../arch/arm64-linux/odp/api/abi/shared_memory.h   |  7 
>  include/odp/arch/default/api/abi/buffer.h  | 34 +
>  include/odp/arch/default/api/abi/classification.h  | 36 ++
>  include/odp/arch/default/api/abi/crypto.h  | 33 
>  include/odp/arch/default/api/abi/event.h   | 39 +++
>  include/odp/arch/default/api/abi/packet.h  | 44 
> ++
>  include/odp/arch/default/api/abi/pool.h| 42 +
>  include/odp/arch/default/api/abi/queue.h   | 34 +
>  include/odp/arch/default/api/abi/shared_memory.h   | 34 +
>  include/odp/arch/mips64-linux/odp/api/abi/buffer.h |  7 
>  .../arch/mips64-linux/odp/api/abi/classification.h |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/crypto.h |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/event.h  |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/packet.h |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/pool.h   |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/queue.h  |  7 
>  .../arch/mips64-linux/odp/api/abi/shared_memory.h  |  7 
>  .../odp/arch/power64-linux/odp/api/abi/buffer.h|  7 
>  .../power64-linux/odp/api/abi/classification.h |  7 
>  .../odp/arch/power64-linux/odp/api/abi/crypto.h|  7 
>  include/odp/arch/power64-linux/odp/api/abi/event.h |  7 
>  

Re: [lng-odp] [PATCH 0/8] First ABI files

[Savolainen, Petri (Nokia - FI/Espoo)]

Thanks, I resent all of them and can see those on the list now.

I don't know what happened. Sometimes a mail server has replied on some patches 
that "cannot be delivered". But this is the first time that a patch was 
silently dropped.

-Petri

> -Original Message-
> From: Mike Holmes [mailto:mike.hol...@linaro.org]
> Sent: Wednesday, January 18, 2017 8:25 PM
> To: Bill Fischofer <bill.fischo...@linaro.org>
> Cc: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> labs.com>; lng-odp-forward <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
> 
> Sorry it is not there, I had that with Yi a while back it took an hour
> to appear on the list and patchworks, for direct recipients it was
> fine
> 
> On 18 January 2017 at 13:23, Mike Holmes <mike.hol...@linaro.org> wrote:
> > I see it on patch works, I think it is this serise
> > http://patches.opendataplane.org/project/lng-odp/list/?series=3
> >
> > On 18 January 2017 at 13:12, Bill Fischofer <bill.fischo...@linaro.org>
> wrote:
> >> Petri, did Part 1/8 of this series not get posted? It doesn't seem to
> >> be on either the mailing list or patchworks.
> >>
> >> Bill

[lng-odp] [PATCH 0/8] First ABI files

[Petri Savolainen]

Added initial version of couple of ABI specification files. These files define 
types/values that are implementation specific in the API spec. For ABI 
compatibility, application and implementation need to use these definitions 
(based on the target architecture). ABI is defined by CPU ISA (including 
version, endianism, etc) and SW environment (OS and compiler). Six different 
ABIs are initially defined - all are Linux based and assume the default 
endianism.

Some unused types were found for API spec. Those will be removed once this 
patch set is merged with api-next.


Petri Savolainen (8):
  abi: event: added the first ABI spec file
  abi: buffer: added initial definitions
  abi: classifier: added initial definitions
  abi: crypto: added initial definitions
  abi: packet: added initial definitions
  abi: pool: added initial definitions
  abi: queue: added initial definitions
  abi: shm: added initial definitions

 configure.ac   | 22 +++
 example/Makefile.inc   |  1 +
 example/timer/odp_timer_test.c |  2 +-
 helper/Makefile.am |  1 +
 include/odp/arch/arm32-linux/odp/api/abi/buffer.h  |  7 
 .../arch/arm32-linux/odp/api/abi/classification.h  |  7 
 include/odp/arch/arm32-linux/odp/api/abi/crypto.h  |  7 
 include/odp/arch/arm32-linux/odp/api/abi/event.h   |  7 
 include/odp/arch/arm32-linux/odp/api/abi/packet.h  |  7 
 include/odp/arch/arm32-linux/odp/api/abi/pool.h|  7 
 include/odp/arch/arm32-linux/odp/api/abi/queue.h   |  7 
 .../arch/arm32-linux/odp/api/abi/shared_memory.h   |  7 
 include/odp/arch/arm64-linux/odp/api/abi/buffer.h  |  7 
 .../arch/arm64-linux/odp/api/abi/classification.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/crypto.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/event.h   |  7 
 include/odp/arch/arm64-linux/odp/api/abi/packet.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/pool.h|  7 
 include/odp/arch/arm64-linux/odp/api/abi/queue.h   |  7 
 .../arch/arm64-linux/odp/api/abi/shared_memory.h   |  7 
 include/odp/arch/default/api/abi/buffer.h  | 34 +
 include/odp/arch/default/api/abi/classification.h  | 36 ++
 include/odp/arch/default/api/abi/crypto.h  | 33 
 include/odp/arch/default/api/abi/event.h   | 39 +++
 include/odp/arch/default/api/abi/packet.h  | 44 ++
 include/odp/arch/default/api/abi/pool.h| 42 +
 include/odp/arch/default/api/abi/queue.h   | 34 +
 include/odp/arch/default/api/abi/shared_memory.h   | 34 +
 include/odp/arch/mips64-linux/odp/api/abi/buffer.h |  7 
 .../arch/mips64-linux/odp/api/abi/classification.h |  7 
 include/odp/arch/mips64-linux/odp/api/abi/crypto.h |  7 
 include/odp/arch/mips64-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/mips64-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/mips64-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/mips64-linux/odp/api/abi/queue.h  |  7 
 .../arch/mips64-linux/odp/api/abi/shared_memory.h  |  7 
 .../odp/arch/power64-linux/odp/api/abi/buffer.h|  7 
 .../power64-linux/odp/api/abi/classification.h |  7 
 .../odp/arch/power64-linux/odp/api/abi/crypto.h|  7 
 include/odp/arch/power64-linux/odp/api/abi/event.h |  7 
 .../odp/arch/power64-linux/odp/api/abi/packet.h|  7 
 include/odp/arch/power64-linux/odp/api/abi/pool.h  |  7 
 include/odp/arch/power64-linux/odp/api/abi/queue.h |  7 
 .../arch/power64-linux/odp/api/abi/shared_memory.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/buffer.h |  7 
 .../arch/x86_32-linux/odp/api/abi/classification.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/crypto.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/queue.h  |  7 
 .../arch/x86_32-linux/odp/api/abi/shared_memory.h  |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/buffer.h |  7 
 .../arch/x86_64-linux/odp/api/abi/classification.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/crypto.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/queue.h  |  7 
 .../arch/x86_64-linux/odp/api/abi/shared_memory.h  |  7 
 platform/Makefile.inc  | 22 +++
 platform/linux-generic/Makefile.am |  1 +
 .../linux-generic/include/odp/api/classification.h |  9 -
 .../include/odp/api/plat/buffer_types.h   

Re: [lng-odp] [PATCH 0/8] First ABI files

[Mike Holmes]

Sorry it is not there, I had that with Yi a while back it took an hour
to appear on the list and patchworks, for direct recipients it was
fine

On 18 January 2017 at 13:23, Mike Holmes  wrote:
> I see it on patch works, I think it is this serise
> http://patches.opendataplane.org/project/lng-odp/list/?series=3
>
> On 18 January 2017 at 13:12, Bill Fischofer  wrote:
>> Petri, did Part 1/8 of this series not get posted? It doesn't seem to
>> be on either the mailing list or patchworks.
>>
>> Bill
>>
>> On Wed, Jan 18, 2017 at 6:56 AM, Petri Savolainen
>>  wrote:
>>> Added initial version of couple of ABI specification files. These files 
>>> define
>>> types/values that are implementation specific in the API spec. For ABI
>>> compatibility, application and implementation need to use these definitions
>>> (based on the target architecture). ABI is defined by CPU ISA (including
>>> version, endianism, etc) and SW environment (OS and compiler). Six different
>>> ABIs are initially defined - all are Linux based and assume the default
>>> endianism.
>>>
>>> Some unused types were found for API spec. Those will be removed once this
>>> patch set is merged with api-next.
>>>
>>>
>>> Petri Savolainen (8):
>>>   abi: event: added the first ABI spec file
>>>   abi: buffer: added initial definitions
>>>   abi: classifier: added initial definitions
>>>   abi: crypto: added initial definitions
>>>   abi: packet: added initial definitions
>>>   abi: pool: added initial definitions
>>>   abi: queue: added initial definitions
>>>   abi: shm: added initial definitions
>>>
>>>  configure.ac   | 22 +++
>>>  example/Makefile.inc   |  1 +
>>>  example/timer/odp_timer_test.c |  2 +-
>>>  helper/Makefile.am |  1 +
>>>  include/odp/arch/arm32-linux/odp/api/abi/buffer.h  |  7 
>>>  .../arch/arm32-linux/odp/api/abi/classification.h  |  7 
>>>  include/odp/arch/arm32-linux/odp/api/abi/crypto.h  |  7 
>>>  include/odp/arch/arm32-linux/odp/api/abi/event.h   |  7 
>>>  include/odp/arch/arm32-linux/odp/api/abi/packet.h  |  7 
>>>  include/odp/arch/arm32-linux/odp/api/abi/pool.h|  7 
>>>  include/odp/arch/arm32-linux/odp/api/abi/queue.h   |  7 
>>>  .../arch/arm32-linux/odp/api/abi/shared_memory.h   |  7 
>>>  include/odp/arch/arm64-linux/odp/api/abi/buffer.h  |  7 
>>>  .../arch/arm64-linux/odp/api/abi/classification.h  |  7 
>>>  include/odp/arch/arm64-linux/odp/api/abi/crypto.h  |  7 
>>>  include/odp/arch/arm64-linux/odp/api/abi/event.h   |  7 
>>>  include/odp/arch/arm64-linux/odp/api/abi/packet.h  |  7 
>>>  include/odp/arch/arm64-linux/odp/api/abi/pool.h|  7 
>>>  include/odp/arch/arm64-linux/odp/api/abi/queue.h   |  7 
>>>  .../arch/arm64-linux/odp/api/abi/shared_memory.h   |  7 
>>>  include/odp/arch/default/api/abi/buffer.h  | 34 +
>>>  include/odp/arch/default/api/abi/classification.h  | 36 ++
>>>  include/odp/arch/default/api/abi/crypto.h  | 33 
>>>  include/odp/arch/default/api/abi/event.h   | 39 +++
>>>  include/odp/arch/default/api/abi/packet.h  | 44 
>>> ++
>>>  include/odp/arch/default/api/abi/pool.h| 42 
>>> +
>>>  include/odp/arch/default/api/abi/queue.h   | 34 +
>>>  include/odp/arch/default/api/abi/shared_memory.h   | 34 +
>>>  include/odp/arch/mips64-linux/odp/api/abi/buffer.h |  7 
>>>  .../arch/mips64-linux/odp/api/abi/classification.h |  7 
>>>  include/odp/arch/mips64-linux/odp/api/abi/crypto.h |  7 
>>>  include/odp/arch/mips64-linux/odp/api/abi/event.h  |  7 
>>>  include/odp/arch/mips64-linux/odp/api/abi/packet.h |  7 
>>>  include/odp/arch/mips64-linux/odp/api/abi/pool.h   |  7 
>>>  include/odp/arch/mips64-linux/odp/api/abi/queue.h  |  7 
>>>  .../arch/mips64-linux/odp/api/abi/shared_memory.h  |  7 
>>>  .../odp/arch/power64-linux/odp/api/abi/buffer.h|  7 
>>>  .../power64-linux/odp/api/abi/classification.h |  7 
>>>  .../odp/arch/power64-linux/odp/api/abi/crypto.h|  7 
>>>  include/odp/arch/power64-linux/odp/api/abi/event.h |  7 
>>>  .../odp/arch/power64-linux/odp/api/abi/packet.h|  7 
>>>  include/odp/arch/power64-linux/odp/api/abi/pool.h  |  7 
>>>  include/odp/arch/power64-linux/odp/api/abi/queue.h |  7 
>>>  .../arch/power64-linux/odp/api/abi/shared_memory.h |  7 
>>>  include/odp/arch/x86_32-linux/odp/api/abi/buffer.h |  7 
>>>  .../arch/x86_32-linux/odp/api/abi/classification.h |  7 
>>>  include/odp/arch/x86_32-linux/odp/api/abi/crypto.h |  7 
>>>  include/odp/arch/x86_32-linux/odp/api/abi/event.h  |  7 
>>>  

Re: [lng-odp] [PATCH 0/8] First ABI files

[Mike Holmes]

I see it on patch works, I think it is this serise
http://patches.opendataplane.org/project/lng-odp/list/?series=3

On 18 January 2017 at 13:12, Bill Fischofer  wrote:
> Petri, did Part 1/8 of this series not get posted? It doesn't seem to
> be on either the mailing list or patchworks.
>
> Bill
>
> On Wed, Jan 18, 2017 at 6:56 AM, Petri Savolainen
>  wrote:
>> Added initial version of couple of ABI specification files. These files 
>> define
>> types/values that are implementation specific in the API spec. For ABI
>> compatibility, application and implementation need to use these definitions
>> (based on the target architecture). ABI is defined by CPU ISA (including
>> version, endianism, etc) and SW environment (OS and compiler). Six different
>> ABIs are initially defined - all are Linux based and assume the default
>> endianism.
>>
>> Some unused types were found for API spec. Those will be removed once this
>> patch set is merged with api-next.
>>
>>
>> Petri Savolainen (8):
>>   abi: event: added the first ABI spec file
>>   abi: buffer: added initial definitions
>>   abi: classifier: added initial definitions
>>   abi: crypto: added initial definitions
>>   abi: packet: added initial definitions
>>   abi: pool: added initial definitions
>>   abi: queue: added initial definitions
>>   abi: shm: added initial definitions
>>
>>  configure.ac   | 22 +++
>>  example/Makefile.inc   |  1 +
>>  example/timer/odp_timer_test.c |  2 +-
>>  helper/Makefile.am |  1 +
>>  include/odp/arch/arm32-linux/odp/api/abi/buffer.h  |  7 
>>  .../arch/arm32-linux/odp/api/abi/classification.h  |  7 
>>  include/odp/arch/arm32-linux/odp/api/abi/crypto.h  |  7 
>>  include/odp/arch/arm32-linux/odp/api/abi/event.h   |  7 
>>  include/odp/arch/arm32-linux/odp/api/abi/packet.h  |  7 
>>  include/odp/arch/arm32-linux/odp/api/abi/pool.h|  7 
>>  include/odp/arch/arm32-linux/odp/api/abi/queue.h   |  7 
>>  .../arch/arm32-linux/odp/api/abi/shared_memory.h   |  7 
>>  include/odp/arch/arm64-linux/odp/api/abi/buffer.h  |  7 
>>  .../arch/arm64-linux/odp/api/abi/classification.h  |  7 
>>  include/odp/arch/arm64-linux/odp/api/abi/crypto.h  |  7 
>>  include/odp/arch/arm64-linux/odp/api/abi/event.h   |  7 
>>  include/odp/arch/arm64-linux/odp/api/abi/packet.h  |  7 
>>  include/odp/arch/arm64-linux/odp/api/abi/pool.h|  7 
>>  include/odp/arch/arm64-linux/odp/api/abi/queue.h   |  7 
>>  .../arch/arm64-linux/odp/api/abi/shared_memory.h   |  7 
>>  include/odp/arch/default/api/abi/buffer.h  | 34 +
>>  include/odp/arch/default/api/abi/classification.h  | 36 ++
>>  include/odp/arch/default/api/abi/crypto.h  | 33 
>>  include/odp/arch/default/api/abi/event.h   | 39 +++
>>  include/odp/arch/default/api/abi/packet.h  | 44 
>> ++
>>  include/odp/arch/default/api/abi/pool.h| 42 
>> +
>>  include/odp/arch/default/api/abi/queue.h   | 34 +
>>  include/odp/arch/default/api/abi/shared_memory.h   | 34 +
>>  include/odp/arch/mips64-linux/odp/api/abi/buffer.h |  7 
>>  .../arch/mips64-linux/odp/api/abi/classification.h |  7 
>>  include/odp/arch/mips64-linux/odp/api/abi/crypto.h |  7 
>>  include/odp/arch/mips64-linux/odp/api/abi/event.h  |  7 
>>  include/odp/arch/mips64-linux/odp/api/abi/packet.h |  7 
>>  include/odp/arch/mips64-linux/odp/api/abi/pool.h   |  7 
>>  include/odp/arch/mips64-linux/odp/api/abi/queue.h  |  7 
>>  .../arch/mips64-linux/odp/api/abi/shared_memory.h  |  7 
>>  .../odp/arch/power64-linux/odp/api/abi/buffer.h|  7 
>>  .../power64-linux/odp/api/abi/classification.h |  7 
>>  .../odp/arch/power64-linux/odp/api/abi/crypto.h|  7 
>>  include/odp/arch/power64-linux/odp/api/abi/event.h |  7 
>>  .../odp/arch/power64-linux/odp/api/abi/packet.h|  7 
>>  include/odp/arch/power64-linux/odp/api/abi/pool.h  |  7 
>>  include/odp/arch/power64-linux/odp/api/abi/queue.h |  7 
>>  .../arch/power64-linux/odp/api/abi/shared_memory.h |  7 
>>  include/odp/arch/x86_32-linux/odp/api/abi/buffer.h |  7 
>>  .../arch/x86_32-linux/odp/api/abi/classification.h |  7 
>>  include/odp/arch/x86_32-linux/odp/api/abi/crypto.h |  7 
>>  include/odp/arch/x86_32-linux/odp/api/abi/event.h  |  7 
>>  include/odp/arch/x86_32-linux/odp/api/abi/packet.h |  7 
>>  include/odp/arch/x86_32-linux/odp/api/abi/pool.h   |  7 
>>  include/odp/arch/x86_32-linux/odp/api/abi/queue.h  |  7 
>>  .../arch/x86_32-linux/odp/api/abi/shared_memory.h  |  7 
>>  include/odp/arch/x86_64-linux/odp/api/abi/buffer.h |  7 
>>  

Re: [lng-odp] [PATCH 0/8] First ABI files

[Bill Fischofer]

Petri, did Part 1/8 of this series not get posted? It doesn't seem to
be on either the mailing list or patchworks.

Bill

On Wed, Jan 18, 2017 at 6:56 AM, Petri Savolainen
 wrote:
> Added initial version of couple of ABI specification files. These files define
> types/values that are implementation specific in the API spec. For ABI
> compatibility, application and implementation need to use these definitions
> (based on the target architecture). ABI is defined by CPU ISA (including
> version, endianism, etc) and SW environment (OS and compiler). Six different
> ABIs are initially defined - all are Linux based and assume the default
> endianism.
>
> Some unused types were found for API spec. Those will be removed once this
> patch set is merged with api-next.
>
>
> Petri Savolainen (8):
>   abi: event: added the first ABI spec file
>   abi: buffer: added initial definitions
>   abi: classifier: added initial definitions
>   abi: crypto: added initial definitions
>   abi: packet: added initial definitions
>   abi: pool: added initial definitions
>   abi: queue: added initial definitions
>   abi: shm: added initial definitions
>
>  configure.ac   | 22 +++
>  example/Makefile.inc   |  1 +
>  example/timer/odp_timer_test.c |  2 +-
>  helper/Makefile.am |  1 +
>  include/odp/arch/arm32-linux/odp/api/abi/buffer.h  |  7 
>  .../arch/arm32-linux/odp/api/abi/classification.h  |  7 
>  include/odp/arch/arm32-linux/odp/api/abi/crypto.h  |  7 
>  include/odp/arch/arm32-linux/odp/api/abi/event.h   |  7 
>  include/odp/arch/arm32-linux/odp/api/abi/packet.h  |  7 
>  include/odp/arch/arm32-linux/odp/api/abi/pool.h|  7 
>  include/odp/arch/arm32-linux/odp/api/abi/queue.h   |  7 
>  .../arch/arm32-linux/odp/api/abi/shared_memory.h   |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/buffer.h  |  7 
>  .../arch/arm64-linux/odp/api/abi/classification.h  |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/crypto.h  |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/event.h   |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/packet.h  |  7 
>  include/odp/arch/arm64-linux/odp/api/abi/pool.h|  7 
>  include/odp/arch/arm64-linux/odp/api/abi/queue.h   |  7 
>  .../arch/arm64-linux/odp/api/abi/shared_memory.h   |  7 
>  include/odp/arch/default/api/abi/buffer.h  | 34 +
>  include/odp/arch/default/api/abi/classification.h  | 36 ++
>  include/odp/arch/default/api/abi/crypto.h  | 33 
>  include/odp/arch/default/api/abi/event.h   | 39 +++
>  include/odp/arch/default/api/abi/packet.h  | 44 
> ++
>  include/odp/arch/default/api/abi/pool.h| 42 +
>  include/odp/arch/default/api/abi/queue.h   | 34 +
>  include/odp/arch/default/api/abi/shared_memory.h   | 34 +
>  include/odp/arch/mips64-linux/odp/api/abi/buffer.h |  7 
>  .../arch/mips64-linux/odp/api/abi/classification.h |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/crypto.h |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/event.h  |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/packet.h |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/pool.h   |  7 
>  include/odp/arch/mips64-linux/odp/api/abi/queue.h  |  7 
>  .../arch/mips64-linux/odp/api/abi/shared_memory.h  |  7 
>  .../odp/arch/power64-linux/odp/api/abi/buffer.h|  7 
>  .../power64-linux/odp/api/abi/classification.h |  7 
>  .../odp/arch/power64-linux/odp/api/abi/crypto.h|  7 
>  include/odp/arch/power64-linux/odp/api/abi/event.h |  7 
>  .../odp/arch/power64-linux/odp/api/abi/packet.h|  7 
>  include/odp/arch/power64-linux/odp/api/abi/pool.h  |  7 
>  include/odp/arch/power64-linux/odp/api/abi/queue.h |  7 
>  .../arch/power64-linux/odp/api/abi/shared_memory.h |  7 
>  include/odp/arch/x86_32-linux/odp/api/abi/buffer.h |  7 
>  .../arch/x86_32-linux/odp/api/abi/classification.h |  7 
>  include/odp/arch/x86_32-linux/odp/api/abi/crypto.h |  7 
>  include/odp/arch/x86_32-linux/odp/api/abi/event.h  |  7 
>  include/odp/arch/x86_32-linux/odp/api/abi/packet.h |  7 
>  include/odp/arch/x86_32-linux/odp/api/abi/pool.h   |  7 
>  include/odp/arch/x86_32-linux/odp/api/abi/queue.h  |  7 
>  .../arch/x86_32-linux/odp/api/abi/shared_memory.h  |  7 
>  include/odp/arch/x86_64-linux/odp/api/abi/buffer.h |  7 
>  .../arch/x86_64-linux/odp/api/abi/classification.h |  7 
>  include/odp/arch/x86_64-linux/odp/api/abi/crypto.h |  7 
>  include/odp/arch/x86_64-linux/odp/api/abi/event.h  |  7 
>  include/odp/arch/x86_64-linux/odp/api/abi/packet.h |  7 
>  include/odp/arch/x86_64-linux/odp/api/abi/pool.h   |  7 

[lng-odp] [PATCH 0/8] First ABI files

[Petri Savolainen]

Added initial version of couple of ABI specification files. These files define 
types/values that are implementation specific in the API spec. For ABI 
compatibility, application and implementation need to use these definitions 
(based on the target architecture). ABI is defined by CPU ISA (including 
version, endianism, etc) and SW environment (OS and compiler). Six different 
ABIs are initially defined - all are Linux based and assume the default 
endianism.

Some unused types were found for API spec. Those will be removed once this 
patch set is merged with api-next.


Petri Savolainen (8):
  abi: event: added the first ABI spec file
  abi: buffer: added initial definitions
  abi: classifier: added initial definitions
  abi: crypto: added initial definitions
  abi: packet: added initial definitions
  abi: pool: added initial definitions
  abi: queue: added initial definitions
  abi: shm: added initial definitions

 configure.ac   | 22 +++
 example/Makefile.inc   |  1 +
 example/timer/odp_timer_test.c |  2 +-
 helper/Makefile.am |  1 +
 include/odp/arch/arm32-linux/odp/api/abi/buffer.h  |  7 
 .../arch/arm32-linux/odp/api/abi/classification.h  |  7 
 include/odp/arch/arm32-linux/odp/api/abi/crypto.h  |  7 
 include/odp/arch/arm32-linux/odp/api/abi/event.h   |  7 
 include/odp/arch/arm32-linux/odp/api/abi/packet.h  |  7 
 include/odp/arch/arm32-linux/odp/api/abi/pool.h|  7 
 include/odp/arch/arm32-linux/odp/api/abi/queue.h   |  7 
 .../arch/arm32-linux/odp/api/abi/shared_memory.h   |  7 
 include/odp/arch/arm64-linux/odp/api/abi/buffer.h  |  7 
 .../arch/arm64-linux/odp/api/abi/classification.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/crypto.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/event.h   |  7 
 include/odp/arch/arm64-linux/odp/api/abi/packet.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/pool.h|  7 
 include/odp/arch/arm64-linux/odp/api/abi/queue.h   |  7 
 .../arch/arm64-linux/odp/api/abi/shared_memory.h   |  7 
 include/odp/arch/default/api/abi/buffer.h  | 34 +
 include/odp/arch/default/api/abi/classification.h  | 36 ++
 include/odp/arch/default/api/abi/crypto.h  | 33 
 include/odp/arch/default/api/abi/event.h   | 39 +++
 include/odp/arch/default/api/abi/packet.h  | 44 ++
 include/odp/arch/default/api/abi/pool.h| 42 +
 include/odp/arch/default/api/abi/queue.h   | 34 +
 include/odp/arch/default/api/abi/shared_memory.h   | 34 +
 include/odp/arch/mips64-linux/odp/api/abi/buffer.h |  7 
 .../arch/mips64-linux/odp/api/abi/classification.h |  7 
 include/odp/arch/mips64-linux/odp/api/abi/crypto.h |  7 
 include/odp/arch/mips64-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/mips64-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/mips64-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/mips64-linux/odp/api/abi/queue.h  |  7 
 .../arch/mips64-linux/odp/api/abi/shared_memory.h  |  7 
 .../odp/arch/power64-linux/odp/api/abi/buffer.h|  7 
 .../power64-linux/odp/api/abi/classification.h |  7 
 .../odp/arch/power64-linux/odp/api/abi/crypto.h|  7 
 include/odp/arch/power64-linux/odp/api/abi/event.h |  7 
 .../odp/arch/power64-linux/odp/api/abi/packet.h|  7 
 include/odp/arch/power64-linux/odp/api/abi/pool.h  |  7 
 include/odp/arch/power64-linux/odp/api/abi/queue.h |  7 
 .../arch/power64-linux/odp/api/abi/shared_memory.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/buffer.h |  7 
 .../arch/x86_32-linux/odp/api/abi/classification.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/crypto.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/queue.h  |  7 
 .../arch/x86_32-linux/odp/api/abi/shared_memory.h  |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/buffer.h |  7 
 .../arch/x86_64-linux/odp/api/abi/classification.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/crypto.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/queue.h  |  7 
 .../arch/x86_64-linux/odp/api/abi/shared_memory.h  |  7 
 platform/Makefile.inc  | 22 +++
 platform/linux-generic/Makefile.am |  1 +
 .../linux-generic/include/odp/api/classification.h |  9 -
 .../include/odp/api/plat/buffer_types.h