Re: [lng-odp] [PATCH 0/8] First ABI files
On Fri, Jan 20, 2017 at 8:22 AM, Savolainen, Petri (Nokia - FI/Espoo) 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) > labs.com> >> Cc: lng-odp-forward >> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files >> >> On Fri, Jan 20, 2017 at 3:33 AM, Savolainen, Petri (Nokia - FI/Espoo) >> 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) > >> labs.com> >> >> Cc: lng-odp-forward >> >> 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
> -Original Message- > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Friday, January 20, 2017 4:13 PM > To: Savolainen, Petri (Nokia - FI/Espoo) labs.com> > Cc: lng-odp-forward > Subject: Re: [lng-odp] [PATCH 0/8] First ABI files > > On Fri, Jan 20, 2017 at 3:33 AM, Savolainen, Petri (Nokia - FI/Espoo) > 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) >> labs.com> > >> Cc: lng-odp-forward > >> 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
On Fri, Jan 20, 2017 at 3:33 AM, Savolainen, Petri (Nokia - FI/Espoo) 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) > labs.com> >> Cc: lng-odp-forward >> 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
> > 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
On Fri, Jan 20, 2017 at 7:22 AM, Mike Holmes 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 wrote: >> On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo) >> 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) >>> labs.com> >>>> Cc: lng-odp-forward >>>> 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
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 wrote: > On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo) > 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) >> labs.com> >>> Cc: lng-odp-forward >>> 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
On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo) 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) > labs.com> >> Cc: lng-odp-forward >> 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
> -Original Message- > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Thursday, January 19, 2017 11:53 PM > To: Savolainen, Petri (Nokia - FI/Espoo) labs.com> > Cc: lng-odp-forward > 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
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(¶ms); 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", ¶ms); 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 > .../odp/arch/power64-linux/odp/
Re: [lng-odp] [PATCH 0/8] First ABI files
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 > Cc: Savolainen, Petri (Nokia - FI/Espoo) labs.com>; lng-odp-forward > 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 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
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 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 >>> include/odp/arch/x86_32-linux/odp/api/abi/packet.h | 7 >>> include/odp/arch/x86_32-linux/odp/api/abi/pool.h | 7
Re: [lng-odp] [PATCH 0/8] First ABI files
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 >> .../arch/x86_64-linux/odp/api/abi/classification.h | 7 >> include/odp/a
Re: [lng-odp] [PATCH 0/8] First ABI files
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 > include/odp/arch/x86_64