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? > > > > -- > With best wishes > Dmitry >
