LNet/socklnd often uses __u32 to hold an ipv4 address.
As we want to extend socklnd to work with IPv6 addresses too,
this needs to change.
This patch changes many __u32s to variants of 'struct sockaddr'.
Library code from sunrpc is used for copying and comparing addresses
rpc_copy_addr() and rpc_cmp_addr()
and for extracting or setting the port:
rpc_get_port() and rpc_set_port().
The "%pIS" printf format is used for printing a sockaddr (works for
both IPv4 and IPv6), and "%pISp" for printing the address with the
port.
The __u32 is in host-byte-order, while addresses in sockaddr are
always network-order, so htonl and ntohl are used as needed.
When storing an address (e.g. in a structure), 'struct
sockaddr_storage' is used. When passing an address to a function,
'struct sockaddr' is used. When an address is known to be IPv4 (i.e.
when converting to or from __u32), 'struct sockaddr_in' is used.
The following functions are changed to take a 'struct sockaddr*'
argument:
lnet_connect()
lnet_connect_console_error()
lnet_sock_getaddr()
ksocknal_ip2iface()
ksocknal_ip2index()
ksocknal_create_route()
ksocknal_connecting()
ksocknal_close_peer_conns_locked()
ksocknal_peer_del_interface_locked()
The following structures have had fields changed to 'struct
sockaddr_storage'
struct ksock_interface:
ksni_ipaddr -> ksni_addr
struct ksock_conn
ksnc_myipaddr -> ksnc_myaddr
ksnc_ipaddr and ksnc_port -> ksnc_peeraddr
struct ksock_route
ksnr_myipaddr -> ksnr_myaddr
ksnr_ipaddr and ksnr_port -> ksnr_addr
Assorted strings have been joined onto a single line, and various
indented have been changed from space to tabs.
There should be no behaviour changes, though the structures mentioned
above will now be a little larger.
Signed-off-by: Mr NeilBrown <neilb@suse.de>
Change-Id: I42d12260185638407b5b611391fc69bfd9f91754
Reviewed-on: https://review.whamcloud.com/37704
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Shaun Tancheff <shaun.tancheff@hpe.com>
Reviewed-by: Aurelien Degremont <degremoa@amazon.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>