No, it won't. I just moved those functions and #defines to the bottom of the same file, and marked them as 'deprecated'.
BR ///jon > -----Original Message----- > From: Jiri Pirko [mailto:j...@resnulli.us] > Sent: Thursday, March 15, 2018 12:11 > To: Jon Maloy <jon.ma...@ericsson.com> > Cc: da...@davemloft.net; netdev@vger.kernel.org; Mohan Krishna Ghanta > Krishnamurthy <mohan.krishna.ghanta.krishnamur...@ericsson.com>; Tung > Quang Nguyen <tung.q.ngu...@dektech.com.au>; Hoang Huu Le > <hoang.h...@dektech.com.au>; Canh Duc Luu > <canh.d....@dektech.com.au>; Ying Xue <ying....@windriver.com>; tipc- > discuss...@lists.sourceforge.net > Subject: Re: [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE > > Thu, Mar 15, 2018 at 04:48:51PM CET, jon.ma...@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 <ying....@windriver.com> > >Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> > > [...] > > > >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?
