From mboxrd@z Thu Jan 1 00:00:00 1970 From: Panu Matilainen Subject: Re: [PATCH 3/3] acl: mark deprecated functions Date: Wed, 17 Jun 2015 10:59:26 +0300 Message-ID: <558128DE.9060802@redhat.com> References: <1434387073-16951-1-git-send-email-stephen@networkplumber.org> <1434387073-16951-4-git-send-email-stephen@networkplumber.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen Hemminger To: Stephen Hemminger , dev@dpdk.org Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id D7EABC3D0 for ; Wed, 17 Jun 2015 09:59:28 +0200 (CEST) In-Reply-To: <1434387073-16951-4-git-send-email-stephen@networkplumber.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 06/15/2015 07:51 PM, Stephen Hemminger wrote: > From: Stephen Hemminger > > To allow for compatiablity with later releases, any functions > to be removed should be marked as deprecated for one release. > > Signed-off-by: Stephen Hemminger [...] > diff --git a/lib/librte_acl/rte_acl.h b/lib/librte_acl/rte_acl.h > index 3a93730..0c32df0 100644 > --- a/lib/librte_acl/rte_acl.h > +++ b/lib/librte_acl/rte_acl.h > @@ -456,7 +456,7 @@ enum { > int > rte_acl_ipv4vlan_add_rules(struct rte_acl_ctx *ctx, > const struct rte_acl_ipv4vlan_rule *rules, > - uint32_t num); > + uint32_t num) __attribute__((deprecated)); > > /** > * Analyze set of ipv4vlan rules and build required internal > @@ -478,7 +478,7 @@ rte_acl_ipv4vlan_add_rules(struct rte_acl_ctx *ctx, > int > rte_acl_ipv4vlan_build(struct rte_acl_ctx *ctx, > const uint32_t layout[RTE_ACL_IPV4VLAN_NUM], > - uint32_t num_categories); > + uint32_t num_categories) __attribute__((deprecated)); > > > #ifdef __cplusplus > I've no objections to the patch as such, but I think the ABI policy is asking all deprecation notices to be added to the "Deprecation Notices" section in the policy document itself. That said, the average developer is MUCH likelier to notice the compiler warning from these than a deprecation notice in some "who reads those" document :) Perhaps we could generate a list of functions marked for removal for the ABI policy document automatically based on the deprecated attributes. - Panu -