Thinking more about this, in a truly consistent command set it might look like this:
"tipc node NODE remove" "tipc node NODE set foo 123" "tipc node NODE set identity NODE" (e.g. "tipc node 0.0.0 set identity 1.1.1") which of course could be abbreviated to "tipc node set identity NODE" since there is only one node where you really can set the identity. ///jon > -----Original Message----- > From: Jon Maloy [mailto:[email protected]] > Sent: Wednesday, 09 December, 2015 07:48 > To: Richard Alpe; [email protected] > Subject: Re: [tipc-discussion] [PATCH iproute2] peer (node) removal from > userspace > > > > -----Original Message----- > > From: Richard Alpe > > Sent: Wednesday, 09 December, 2015 05:07 > > To: [email protected] > > Cc: Jon Maloy; Ying Xue; Richard Alpe > > Subject: [PATCH iproute2] peer (node) removal from userspace > > > > I first implemented node remove as "tipc node remove address ADDRESS", > > then I noticed there is a "tipc node set address ADDRESS". These > > should of course be each others counterparts. This made me realise > > that "node remove" is really a "peer remove". So it became "tipc peer > > remove address 1.1.2", > > To me "node" always meant node in general, i.e., both peer AND own node. > > > where address is used as peer identifier. > > When an address it is used to identify the a node there is no need to specify > the keyword "address"; it is not the address of the node you are removing, it > is the node object itself. So why not just "tipc node ADDRESS remove" ? > > It is possible that this should be changed elsewhere too, for consistency. > > > An example of how this scale > > could be "tipc peer set foo 123 address ADDRESS" where we set foo to > > 123 for a specific peer to 123. > > or "tipc node ADDRESS set foo 123" > > This is also why, as earlier mentioned, I would prefer the term "identity" to > "address" in those cases. We are really talking about a node identity here, > not an address (of which each node may have several, IP, MAC...). > > ///jon > > > > > This also made me realize that "tipc node list" should really be "tipc peer > list". > > I guess we should implement "tipc peer list" as a clone of "tipc node > > list" and deprecate the later? > > > > The remaining question and the primary reason for this cover letter > > is, should I change the kernel define for this as well? From > > TIPC_NL_NODE_REMOVE to TIPC_NL_PEER_REMOVE? I'm not sure how it > would > > fit in the current curnel space context. Note that this is not yet merged. > > > > Richard Alpe (1): > > tipc: add peer remove functionality > > > > include/linux/tipc_netlink.h | 1 + > > man/man8/tipc-bearer.8 | 1 + > > man/man8/tipc-link.8 | 1 + > > man/man8/tipc-media.8 | 1 + > > man/man8/tipc-nametable.8 | 1 + > > man/man8/tipc-node.8 | 1 + > > man/man8/tipc-peer.8 | 52 +++++++++++++++++++++++++ > > man/man8/tipc.8 | 1 + > > tipc/Makefile | 2 +- > > tipc/peer.c | 93 > > ++++++++++++++++++++++++++++++++++++++++++++ > > tipc/peer.h | 21 ++++++++++ > > tipc/tipc.c | 3 ++ > > 12 files changed, 177 insertions(+), 1 deletion(-) create mode > > 100644 > > man/man8/tipc-peer.8 create mode 100644 tipc/peer.c create mode > > 100644 tipc/peer.h > > > > -- > > 2.1.4 > > > ------------------------------------------------------------------------------ > _______________________________________________ > tipc-discussion mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tipc-discussion ------------------------------------------------------------------------------ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
