Re: [PATCH v4 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h
On (10/16/15 01:39), Mikko Rapeli wrote: > "uint32_t vs __u32" nail is: > https://lkml.org/lkml/2015/6/1/160 shrug. BTW, doesn't having the exported rds.h use __foo everywhere actually end up with the result that "the kernel use the same names as user space" --Sowmini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h
On Thu, Oct 15, 2015 at 06:21:05PM -0400, Sowmini Varadhan wrote: > On (10/16/15 01:00), Mikko Rapeli wrote: > > > > What kind of portability should exported userspace headers from Linux kernel > > need? > > > > Reviews to my previous changes NACKed usage and > > Documentation/CodingStyle chapter 5 says: > > > > (e) Types safe for use in userspace. > > > > In certain structures which are visible to userspace, we cannot > > require C99 types and cannot use the 'u32' form above. Thus, we > > use __u32 and similar types in all structures which are shared > > with userspace. > > Let's be clear: we are not talking about u32 vs __u32, we are talking > about uint32_t vs __u32 in your patch. > > I dont have the context of your "previous changes NACKed.." etc. > Why can we not require C99 types in rds.h? Links to all previous reviews are here: https://lkml.org/lkml/2015/10/15/22 "uint32_t vs __u32" nail is: https://lkml.org/lkml/2015/6/1/160 > Why isnt that a problem for, say, which includes > ? isn't from Linux kernel, it comes from libc. is from Linux kernel and that does not include . But this brough to my attention so thanks for that. Maybe the vs. conflict could be resolved with it. -Mikko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h
On (10/16/15 01:00), Mikko Rapeli wrote: > > What kind of portability should exported userspace headers from Linux kernel > need? > > Reviews to my previous changes NACKed usage and > Documentation/CodingStyle chapter 5 says: > > (e) Types safe for use in userspace. > > In certain structures which are visible to userspace, we cannot > require C99 types and cannot use the 'u32' form above. Thus, we > use __u32 and similar types in all structures which are shared > with userspace. Let's be clear: we are not talking about u32 vs __u32, we are talking about uint32_t vs __u32 in your patch. I dont have the context of your "previous changes NACKed.." etc. Why can we not require C99 types in rds.h? Why isnt that a problem for, say, which includes ? --Sowmini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h
On Thu, Oct 15, 2015 at 07:06:14AM -0400, Sowmini Varadhan wrote: > On (10/15/15 07:56), Mikko Rapeli wrote: > > Date: Thu, 15 Oct 2015 07:56:01 +0200 > > From: Mikko Rapeli > > To: linux-kernel@vger.kernel.org > > Cc: mikko.rap...@iki.fi, "David S. Miller" , Sowmini > > Varadhan , linux-...@vger.kernel.org > > Subject: [PATCH v4 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64 > > from linux/types.h > > X-Mailer: git-send-email 2.6.1 > > > > Fixes userspace compilation errors like: > > > > linux/rds.h:96:2: error: unknown type name ‘uint8_t’ > > Can't you just include in linux/rds.h? (similar to the > fix for linux/rds)? It would reduce the deltas significantly, > and portable applications are likely to expect uint8_t etc anyway. What kind of portability should exported userspace headers from Linux kernel need? Reviews to my previous changes NACKed usage and Documentation/CodingStyle chapter 5 says: (e) Types safe for use in userspace. In certain structures which are visible to userspace, we cannot require C99 types and cannot use the 'u32' form above. Thus, we use __u32 and similar types in all structures which are shared with userspace. -Mikko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h
On (10/15/15 07:56), Mikko Rapeli wrote: > Date: Thu, 15 Oct 2015 07:56:01 +0200 > From: Mikko Rapeli > To: linux-kernel@vger.kernel.org > Cc: mikko.rap...@iki.fi, "David S. Miller" , Sowmini > Varadhan , linux-...@vger.kernel.org > Subject: [PATCH v4 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64 > from linux/types.h > X-Mailer: git-send-email 2.6.1 > > Fixes userspace compilation errors like: > > linux/rds.h:96:2: error: unknown type name ‘uint8_t’ Can't you just include in linux/rds.h? (similar to the fix for linux/rds)? It would reduce the deltas significantly, and portable applications are likely to expect uint8_t etc anyway. --Sowmini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 23/79] rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h
Fixes userspace compilation errors like:
linux/rds.h:96:2: error: unknown type name ‘uint8_t’
Signed-off-by: Mikko Rapeli
---
include/uapi/linux/rds.h | 102 +++
1 file changed, 51 insertions(+), 51 deletions(-)
diff --git a/include/uapi/linux/rds.h b/include/uapi/linux/rds.h
index 0f9265c..539f9f8 100644
--- a/include/uapi/linux/rds.h
+++ b/include/uapi/linux/rds.h
@@ -103,8 +103,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
@@ -114,35 +114,35 @@ struct rds_info_counter {
#define TRANSNAMSIZ16
struct rds_info_connection {
- uint64_tnext_tx_seq;
- uint64_tnext_rx_seq;
+ __u64 next_tx_seq;
+ __u64 next_rx_seq;
__be32 laddr;
__be32 faddr;
- uint8_t transport[TRANSNAMSIZ]; /* null term ascii */
- uint8_t flags;
+ __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;
+ __u64 seq;
+ __u32 len;
__be32 laddr;
__be32 faddr;
__be16 lport;
__be16 fport;
- uint8_t flags;
+ __u8flags;
} __attribute__((packed));
struct rds_info_socket {
- uint32_tsndbuf;
+ __u32 sndbuf;
__be32 bound_addr;
__be32 connected_addr;
__be16 bound_port;
__be16 connected_port;
- uint32_trcvbuf;
- uint64_tinum;
+ __u32 rcvbuf;
+ __u64 inum;
} __attribute__((packed));
struct rds_info_tcp_socket {
@@ -150,25 +150,25 @@ struct rds_info_tcp_socket {
__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;
+ __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];
+ __u8src_gid[RDS_IB_GID_LEN];
+ __u8dst_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;
+ __u32 max_send_wr;
+ __u32 max_recv_wr;
+ __u32 max_send_sge;
+ __u32 rdma_mr_max;
+ __u32 rdma_mr_size;
};
/*
@@ -209,70 +209,70 @@ struct rds_info_rdma_connection {
* (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_tcookie_addr;
- uint64_tflags;
+ __u64 cookie_addr;
+ __u64 flags;
};
struct rds_free_mr_args {
rds_rdma_cookie_t cookie;
- uint64_tflags;
+ __u64 flags;
};
struct rds_rdma_args {
rds_rdma_cookie_t cookie;
struct rds_iovec remote_vec;
- uint64_tlocal_vec_addr;
- uint64_tnr_local;
- uint64_tflags;
- uint64_tuser_token;
+ __u64 local_vec_addr;
+ __u64 nr_local;
+ __u64 flags;
+ __u64 user_token;
};
struct rds_atomic_args {
rds_rdma_cookie_t cookie;
- uint64_tlocal_addr;
- uint64_tremote_addr;
+ __u64 local_addr;
+ __u64 remote_addr;
union {
struct {
- uint64_tcompare;
- uint64_tswap;
+ __u64 compare;
+ __u64 swap;
} cswp;
struct {
-
