From: Jiri Pirko <jiri@resnulli•us>
To: Jon Maloy <jon.maloy@ericsson•com>
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
Date: Thu, 15 Mar 2018 17:11:22 +0100 [thread overview]
Message-ID: <20180315161122.GH2130@nanopsycho> (raw)
In-Reply-To: <1521128935-6141-3-git-send-email-jon.maloy@ericsson.com>
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 <ying.xue@windriver•com>
>Signed-off-by: Jon Maloy <jon.maloy@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?
next prev parent reply other threads:[~2018-03-15 16:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 15:48 [net-next 0/5] tipc: obsolete zone concept Jon Maloy
2018-03-15 15:48 ` Jon Maloy
2018-03-15 15:48 ` [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE Jon Maloy
2018-03-15 16:11 ` Jiri Pirko [this message]
2018-03-15 16:27 ` Jon Maloy
2018-03-15 16:37 ` Jiri Pirko
2018-03-15 15:48 ` [net-next 2/5] tipc: remove zone publication list in name table Jon Maloy
2018-03-15 15:48 ` [net-next 3/5] tipc: remove zone_list member in struct publication Jon Maloy
2018-03-15 15:48 ` [net-next 4/5] tipc: merge two lists " Jon Maloy
2018-03-15 15:48 ` [net-next 5/5] tipc: some name changes Jon Maloy
2018-03-17 21:12 ` [net-next 0/5] tipc: obsolete zone concept David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180315161122.GH2130@nanopsycho \
--to=jiri@resnulli$(echo .)us \
--cc=canh.d.luu@dektech$(echo .)com.au \
--cc=davem@davemloft$(echo .)net \
--cc=hoang.h.le@dektech$(echo .)com.au \
--cc=jon.maloy@ericsson$(echo .)com \
--cc=mohan.krishna.ghanta.krishnamurthy@ericsson$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=tipc-discussion@lists$(echo .)sourceforge.net \
--cc=tung.q.nguyen@dektech$(echo .)com.au \
--cc=ying.xue@windriver$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox