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.



-- 
With best wishes
Dmitry

Reply via email to