From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f196.google.com ([209.85.128.196]:38790 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750745AbeCOQLY (ORCPT ); Thu, 15 Mar 2018 12:11:24 -0400 Received: by mail-wr0-f196.google.com with SMTP id l8so8880010wrg.5 for ; Thu, 15 Mar 2018 09:11:24 -0700 (PDT) Date: Thu, 15 Mar 2018 17:11:22 +0100 From: Jiri Pirko To: Jon Maloy Cc: davem@davemloft.net, netdev@vger.kernel.org, mohan.krishna.ghanta.krishnamurthy@ericsson.com, tung.q.nguyen@dektech.com.au, hoang.h.le@dektech.com.au, canh.d.luu@dektech.com.au, ying.xue@windriver.com, tipc-discussion@lists.sourceforge.net Subject: Re: [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE Message-ID: <20180315161122.GH2130@nanopsycho> References: <1521128935-6141-1-git-send-email-jon.maloy@ericsson.com> <1521128935-6141-3-git-send-email-jon.maloy@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1521128935-6141-3-git-send-email-jon.maloy@ericsson.com> Sender: netdev-owner@vger.kernel.org List-ID: Thu, Mar 15, 2018 at 04:48:51PM CET, jon.maloy@ericsson.com wrote: >Publications for TIPC_CLUSTER_SCOPE and TIPC_ZONE_SCOPE are in all >aspects handled the same way, both on the publishing node and on the >receiving nodes. > >Despite previous ambitions to the contrary, this is never going to change, >so we take the conseqeunce of this and obsolete TIPC_ZONE_SCOPE and related >macros/functions. Whenever a user is doing a bind() or a sendmsg() attempt >using ZONE_SCOPE we translate this internally to CLUSTER_SCOPE, while we >remain compatible with users and remote nodes still using ZONE_SCOPE. > >Furthermore, the non-formalized scope value 0 has always been permitted >for use during lookup, with the same meaning as ZONE_SCOPE/CLUSTER_SCOPE. >We now permit it even as binding scope, but for compatibility reasons we >choose to not change the value of TIPC_CLUSTER_SCOPE. > >Acked-by: Ying Xue >Signed-off-by: Jon Maloy [...] >diff --git a/include/uapi/linux/tipc.h b/include/uapi/linux/tipc.h >index 14bacc7..4ac9f1f 100644 >--- a/include/uapi/linux/tipc.h >+++ b/include/uapi/linux/tipc.h >@@ -61,50 +61,6 @@ struct tipc_name_seq { > __u32 upper; > }; > >-/* TIPC Address Size, Offset, Mask specification for Z.C.N >- */ >-#define TIPC_NODE_BITS 12 >-#define TIPC_CLUSTER_BITS 12 >-#define TIPC_ZONE_BITS 8 >- >-#define TIPC_NODE_OFFSET 0 >-#define TIPC_CLUSTER_OFFSET TIPC_NODE_BITS >-#define TIPC_ZONE_OFFSET (TIPC_CLUSTER_OFFSET + TIPC_CLUSTER_BITS) >- >-#define TIPC_NODE_SIZE ((1UL << TIPC_NODE_BITS) - 1) >-#define TIPC_CLUSTER_SIZE ((1UL << TIPC_CLUSTER_BITS) - 1) >-#define TIPC_ZONE_SIZE ((1UL << TIPC_ZONE_BITS) - 1) >- >-#define TIPC_NODE_MASK (TIPC_NODE_SIZE << TIPC_NODE_OFFSET) >-#define TIPC_CLUSTER_MASK (TIPC_CLUSTER_SIZE << TIPC_CLUSTER_OFFSET) >-#define TIPC_ZONE_MASK (TIPC_ZONE_SIZE << TIPC_ZONE_OFFSET) >- >-#define TIPC_ZONE_CLUSTER_MASK (TIPC_ZONE_MASK | TIPC_CLUSTER_MASK) >- >-static inline __u32 tipc_addr(unsigned int zone, >- unsigned int cluster, >- unsigned int node) >-{ >- return (zone << TIPC_ZONE_OFFSET) | >- (cluster << TIPC_CLUSTER_OFFSET) | >- node; >-} >- >-static inline unsigned int tipc_zone(__u32 addr) >-{ >- return addr >> TIPC_ZONE_OFFSET; >-} >- >-static inline unsigned int tipc_cluster(__u32 addr) >-{ >- return (addr & TIPC_CLUSTER_MASK) >> TIPC_CLUSTER_OFFSET; >-} >- >-static inline unsigned int tipc_node(__u32 addr) >-{ >- return addr & TIPC_NODE_MASK; >-} If someone includes tipc.h and uses any of this, your patch is going to break his compilation. Would anyone have good reason to use any of this?