[net-next][PATCH v2] RDS: Make user visible data types consistent with rest of the kernel

2017-02-20 Thread Santosh Shilimkar
Use "__uX/__sX" kernel types rather than current uint*/int* for
entire file.

Reviewed-by: Sowmini Varadhan 
Signed-off-by: Santosh Shilimkar 
---
v1->v2:
As suggested by David Miller, cleaned up entire header to use kernel types.

 include/uapi/linux/rds.h | 146 +++
 1 file changed, 73 insertions(+), 73 deletions(-)

diff --git a/include/uapi/linux/rds.h b/include/uapi/linux/rds.h
index 3833113..1eafad4 100644
--- a/include/uapi/linux/rds.h
+++ b/include/uapi/linux/rds.h
@@ -117,8 +117,8 @@
 #define RDS_INFO_LAST  10010
 
 struct rds_info_counter {
-   uint8_t name[32];
-   uint64_tvalue;
+   __u8name[32];
+   __u64   value;
 } __attribute__((packed));
 
 #define RDS_INFO_CONNECTION_FLAG_SENDING   0x01
@@ -128,61 +128,61 @@ struct rds_info_counter {
 #define TRANSNAMSIZ16
 
 struct rds_info_connection {
-   uint64_tnext_tx_seq;
-   uint64_tnext_rx_seq;
-   __be32  laddr;
-   __be32  faddr;
-   uint8_t transport[TRANSNAMSIZ]; /* null term ascii */
-   uint8_t flags;
+   __u64   next_tx_seq;
+   __u64   next_rx_seq;
+   __be32  laddr;
+   __be32  faddr;
+   __u8transport[TRANSNAMSIZ]; /* null term ascii */
+   __u8flags;
 } __attribute__((packed));
 
 #define RDS_INFO_MESSAGE_FLAG_ACK   0x01
 #define RDS_INFO_MESSAGE_FLAG_FAST_ACK  0x02
 
 struct rds_info_message {
-   uint64_tseq;
-   uint32_tlen;
-   __be32  laddr;
-   __be32  faddr;
-   __be16  lport;
-   __be16  fport;
-   uint8_t flags;
+   __u64   seq;
+   __u32   len;
+   __be32  laddr;
+   __be32  faddr;
+   __be16  lport;
+   __be16  fport;
+   __u8flags;
 } __attribute__((packed));
 
 struct rds_info_socket {
-   uint32_tsndbuf;
-   __be32  bound_addr;
-   __be32  connected_addr;
-   __be16  bound_port;
-   __be16  connected_port;
-   uint32_trcvbuf;
-   uint64_tinum;
+   __u32   sndbuf;
+   __be32  bound_addr;
+   __be32  connected_addr;
+   __be16  bound_port;
+   __be16  connected_port;
+   __u32   rcvbuf;
+   __u64   inum;
 } __attribute__((packed));
 
 struct rds_info_tcp_socket {
-   __be32  local_addr;
-   __be16  local_port;
-   __be32  peer_addr;
-   __be16  peer_port;
-   uint64_t   hdr_rem;
-   uint64_t   data_rem;
-   uint32_t   last_sent_nxt;
-   uint32_t   last_expected_una;
-   uint32_t   last_seen_una;
+   __be32  local_addr;
+   __be16  local_port;
+   __be32  peer_addr;
+   __be16  peer_port;
+   __u64   hdr_rem;
+   __u64   data_rem;
+   __u32   last_sent_nxt;
+   __u32   last_expected_una;
+   __u32   last_seen_una;
 } __attribute__((packed));
 
 #define RDS_IB_GID_LEN 16
 struct rds_info_rdma_connection {
-   __be32  src_addr;
-   __be32  dst_addr;
-   uint8_t src_gid[RDS_IB_GID_LEN];
-   uint8_t dst_gid[RDS_IB_GID_LEN];
-
-   uint32_tmax_send_wr;
-   uint32_tmax_recv_wr;
-   uint32_tmax_send_sge;
-   uint32_trdma_mr_max;
-   uint32_trdma_mr_size;
+   __be32  src_addr;
+   __be32  dst_addr;
+   __u8src_gid[RDS_IB_GID_LEN];
+   __u8dst_gid[RDS_IB_GID_LEN];
+
+   __u32   max_send_wr;
+   __u32   max_recv_wr;
+   __u32   max_send_sge;
+   __u32   rdma_mr_max;
+   __u32   rdma_mr_size;
 };
 
 /* RDS message Receive Path Latency points */
@@ -194,14 +194,14 @@ enum rds_message_rxpath_latency {
 };
 
 struct rds_rx_trace_so {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   __u8 rx_traces;
+   __u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 struct rds_cmsg_rx_trace {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
-   u64 rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   __u8 rx_traces;
+   __u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   __u64 rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 /*
@@ -242,70 +242,70 @@ struct rds_cmsg_rx_trace {
  * (so that the application does not have to worry about
  * alignment).
  */
-typedef uint64_t   rds_rdma_cookie_t;
+typedef __u64  rds_rdma_cookie_t;
 
 struct rds_iovec {
-   uint64_taddr;
-   uint64_tbytes;
+   __u64   addr;
+   __u64   bytes;
 };
 
 struct rds_get_mr_args {
struct rds_iovec vec;
-   uint64_tcookie_addr;
-   uint64_tflags;
+   __u64   cookie_addr;
+   __u64   flags;
 };
 
 struct rds_get_mr_for_dest_args {
struct sockaddr_storage dest_addr;
struct rds_iovecvec;
-   uint64_tcoo

Re: [net-next][PATCH v2] RDS: Make user visible data types consistent with rest of the kernel

2017-02-20 Thread David Miller
From: Santosh Shilimkar 
Date: Mon, 20 Feb 2017 14:16:53 -0800

> Use "__uX/__sX" kernel types rather than current uint*/int* for
> entire file.
> 
> Reviewed-by: Sowmini Varadhan 
> Signed-off-by: Santosh Shilimkar 
> ---
> v1->v2:
> As suggested by David Miller, cleaned up entire header to use kernel types.

Dmitry Levin already submitted a patch the other day which does this,
and it is already in net-next.


Re: [net-next][PATCH v2] RDS: Make user visible data types consistent with rest of the kernel

2017-02-21 Thread santosh.shilim...@oracle.com

On 2/20/17 7:18 PM, David Miller wrote:

From: Santosh Shilimkar 
Date: Mon, 20 Feb 2017 14:16:53 -0800


Use "__uX/__sX" kernel types rather than current uint*/int* for
entire file.

Reviewed-by: Sowmini Varadhan 
Signed-off-by: Santosh Shilimkar 
---
v1->v2:
As suggested by David Miller, cleaned up entire header to use kernel types.


Dmitry Levin already submitted a patch the other day which does this,
and it is already in net-next.


I see that now. Thanks Dave !!

Regards,
Santosh