On 14 July 2017 at 04:33, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> > > On Thu, Jul 13, 2017 at 4:32 PM, Dmitry Eremin-Solenikov < > dmitry.ereminsoleni...@linaro.org> wrote: > >> On 13.07.2017 21:20, Bill Fischofer wrote: >> > On Thu, Jul 13, 2017 at 12:58 PM, Bala Manoharan >> > <bala.manoha...@linaro.org> wrote: >> >> On 13 July 2017 at 16:25, Savolainen, Petri (Nokia - FI/Espoo) < >> >> petri.savolai...@nokia.com> wrote: >> >> >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of >> >>>> Github ODP bot >> >>>> Sent: Wednesday, July 12, 2017 5:00 PM >> >>>> To: lng-odp@lists.linaro.org >> >>>> Subject: [lng-odp] [PATCH API-NEXT v2 4/4] api: crypto: revert >> >>> deprecation >> >>>> of crypto completion API >> >>>> >> >>>> From: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org> >> >>>> >> >>>> It was decided that it would be benefitable to live with both API >> types >> >>>> at this point, as odp_crypto_compl_t was available for some time. So >> >>>> undeprecate odp_crypto_compl_t and related functionality. Validation >> >>>> tests also provide necessary tests for pref_mode and for completion >> >>>> event. >> >>>> >> >>>> Signed-off-by: Dmitry Eremin-Solenikov <dmitry.ereminsolenikov@linaro >> >>> .org> >> >>>> --- >> >>>> /** Email created from pull request 74 (lumag:crypto-packet) >> >>>> ** https://github.com/Linaro/odp/pull/74 >> >>>> ** Patch: https://github.com/Linaro/odp/pull/74.patch >> >>>> ** Base sha: ee5be324411a7520528a367967c28fc529d3bc2e >> >>>> ** Merge commit sha: 5411462e6545fa2d6a286a40c2057db97714ee74 >> >>>> **/ >> >>>> include/odp/api/spec/crypto.h | 38 >> >>> +++++++---------- >> >>>> --- >> >>>> include/odp/arch/default/api/abi/crypto.h | 4 +-- >> >>>> include/odp/arch/default/api/abi/event.h | 4 +-- >> >>>> .../include/odp/api/plat/crypto_types.h | 3 +- >> >>>> .../include/odp/api/plat/event_types.h | 3 +- >> >>>> platform/linux-generic/odp_crypto.c | 4 --- >> >>>> platform/linux-generic/odp_event.c | 2 -- >> >>>> test/common_plat/performance/odp_crypto.c | 1 + >> >>>> test/common_plat/validation/api/crypto/crypto.c | 2 ++ >> >>>> .../validation/api/crypto/odp_crypto_test_inp.c | 41 >> >>>> +++++++++++++++++++++- >> >>>> .../validation/api/crypto/odp_crypto_test_inp.h | 2 ++ >> >>>> 11 files changed, 61 insertions(+), 43 deletions(-) >> >>>> >> >>>> diff --git a/include/odp/api/spec/crypto.h >> >>> b/include/odp/api/spec/crypto.h >> >>>> index 3e47f3ef..6736214b 100644 >> >>>> --- a/include/odp/api/spec/crypto.h >> >>>> +++ b/include/odp/api/spec/crypto.h >> >>>> @@ -271,11 +271,8 @@ typedef struct odp_crypto_session_param_t { >> >>>> */ >> >>>> odp_bool_t auth_cipher_text; >> >>>> >> >>>> - /** Preferred sync vs. async >> >>>> - * >> >>>> - * @deprecated no-op now, odp_crypto_operation() will always >> >>>> process >> >>>> - * data in non-posted mode */ >> >>>> - odp_crypto_op_mode_t ODP_DEPRECATE(pref_mode); >> >>>> + /** Preferred sync vs. async for odp_crypto_operation() */ >> >>>> + odp_crypto_op_mode_t pref_mode; >> >>> >> >>> Maybe it makes still sense to leave these @deprecated doxygen tags >> into >> >>> documentation. So, that we (and user) have some means to follow where >> goes >> >>> to line between new and old API. Old API documentation should not >> change, >> >>> but just tag those that are part of the old API and will be removed in >> >>> future. >> >>> >> >>> As agreed, we'll leave out ODP_DEPRECATE() macros in this first >> phase. Add >> >>> those in next phase, and remove in the last phase. >> >>> Ti >> >>> -Petri >> >>> >> >> >> >> IMO we could add deprecated after Tigermoth or get opinion from >> multiple >> >> customers regarding deprecating this API. >> >> Atleast for Tigermoth these APIs should not be declared or indicated as >> >> deprecated. >> >> >> > >> > Bala, >> > >> > Would you be OK with the Tiger Moth release notes and/or User Guide >> > indicating that the intent is to deprecate these APIs in a future >> > release? I just think it's reasonable to give customers notice that >> > they should be thinking about migrating to the newer APIs with as much >> > lead time as possible. >> >> Let's skip 'deprecation' for Tiger Moth even in documentation: an >> indication that examples and perf test use only packet API should be >> enough, while still getting useful feedback from customers/users who >> would be able to compare to API approaches. >> > > OK, I'll post a User Guide update describing the new APIs and perhaps > suggesting that they represent preferred forms? > Maybe you can suggest in User guide that the new APIs are preferred if application is only interested in either sync or async mode. Regards, Bala > > >> >> >> >> -- >> With best wishes >> Dmitry >> > >
