[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM5PR15MB15620DD9157E5EAECB63941E9AD00@DM5PR15MB1562.namprd15.prod.outlook.com>
Date: Thu, 15 Mar 2018 16:27:17 +0000
From: Jon Maloy <jon.maloy@...csson.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Mohan Krishna Ghanta Krishnamurthy
<mohan.krishna.ghanta.krishnamurthy@...csson.com>,
Tung Quang Nguyen <tung.q.nguyen@...tech.com.au>,
Hoang Huu Le <hoang.h.le@...tech.com.au>,
Canh Duc Luu <canh.d.luu@...tech.com.au>,
Ying Xue <ying.xue@...driver.com>,
"tipc-discussion@...ts.sourceforge.net"
<tipc-discussion@...ts.sourceforge.net>
Subject: RE: [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE
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:jiri@...nulli.us]
> Sent: Thursday, March 15, 2018 12:11
> To: Jon Maloy <jon.maloy@...csson.com>
> Cc: davem@...emloft.net; netdev@...r.kernel.org; Mohan Krishna Ghanta
> Krishnamurthy <mohan.krishna.ghanta.krishnamurthy@...csson.com>; Tung
> Quang Nguyen <tung.q.nguyen@...tech.com.au>; Hoang Huu Le
> <hoang.h.le@...tech.com.au>; Canh Duc Luu
> <canh.d.luu@...tech.com.au>; Ying Xue <ying.xue@...driver.com>; tipc-
> discussion@...ts.sourceforge.net
> Subject: Re: [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE
>
> Thu, Mar 15, 2018 at 04:48:51PM CET, jon.maloy@...csson.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.xue@...driver.com>
> >Signed-off-by: Jon Maloy <jon.maloy@...csson.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?
Powered by blists - more mailing lists