* [RFC 0/2] Eliminate zero length arrays in DPDK
@ 2022-02-15 23:00 Stephen Hemminger
2022-02-15 23:00 ` [RFC 1/2] devtools: add script to check for zero length array Stephen Hemminger
` (4 more replies)
0 siblings, 5 replies; 14+ messages in thread
From: Stephen Hemminger @ 2022-02-15 23:00 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Yet another case of applying Linux kernel best practices
to DPDK. Flexible arrays are supported by Clang, GCC and
Microsoft compilers (part of C99).
Stephen Hemminger (2):
devtools: add script to check for zero length array
treewide: replace zero-length array with flex array
app/test/test_table_tables.c | 2 +-
devtools/cocci/zerolengtharray.cocci | 17 +++++++++++++++++
drivers/bus/dpaa/include/netcfg.h | 4 ++--
drivers/common/cnxk/roc_se.h | 2 +-
drivers/common/dpaax/caamflib/desc/ipsec.h | 2 +-
drivers/common/dpaax/dpaax_iova_table.h | 2 +-
drivers/common/mlx5/mlx5_prm.h | 8 ++++----
drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 2 +-
drivers/crypto/ipsec_mb/ipsec_mb_private.h | 4 ++--
drivers/crypto/virtio/virtio_ring.h | 4 ++--
drivers/crypto/virtio/virtqueue.h | 2 +-
drivers/net/cxgbe/clip_tbl.h | 2 +-
drivers/net/cxgbe/l2t.h | 2 +-
drivers/net/cxgbe/mps_tcam.h | 2 +-
drivers/net/cxgbe/smt.h | 2 +-
drivers/net/enic/base/vnic_devcmd.h | 4 ++--
drivers/net/hinic/hinic_pmd_tx.h | 2 +-
drivers/net/nfp/nfpcore/nfp_nsp.h | 2 +-
drivers/net/virtio/virtio_ring.h | 4 ++--
drivers/net/virtio/virtio_user/vhost_kernel.c | 2 +-
drivers/net/virtio/virtio_user/vhost_vdpa.c | 2 +-
drivers/net/virtio/virtqueue.h | 2 +-
drivers/regex/mlx5/mlx5_rxp.h | 2 +-
examples/ip_reassembly/main.c | 2 +-
lib/cryptodev/cryptodev_pmd.h | 2 +-
lib/cryptodev/rte_cryptodev.h | 2 +-
lib/ip_frag/ip_reassembly.h | 2 +-
lib/ipsec/sa.h | 2 +-
lib/rib/rte_rib.c | 2 +-
lib/rib/rte_rib6.c | 2 +-
lib/table/rte_swx_table_learner.c | 2 +-
lib/table/rte_table_hash_key16.c | 4 ++--
lib/table/rte_table_hash_key32.c | 4 ++--
lib/table/rte_table_hash_key8.c | 4 ++--
lib/vhost/rte_vhost.h | 4 ++--
35 files changed, 63 insertions(+), 46 deletions(-)
create mode 100644 devtools/cocci/zerolengtharray.cocci
--
2.34.1
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC 1/2] devtools: add script to check for zero length array
2022-02-15 23:00 [RFC 0/2] Eliminate zero length arrays in DPDK Stephen Hemminger
@ 2022-02-15 23:00 ` Stephen Hemminger
2022-02-15 23:00 ` [RFC 2/2] treewide: replace zero-length array with flex array Stephen Hemminger
` (3 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Stephen Hemminger @ 2022-02-15 23:00 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Use the same script as Linux kernel to find and replace
zero length arrays at end of structures.
Flexible arrays were introduced in C99 and help catch
some obvious errors (like incorrect sizeof).
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
devtools/cocci/zerolengtharray.cocci | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 devtools/cocci/zerolengtharray.cocci
diff --git a/devtools/cocci/zerolengtharray.cocci b/devtools/cocci/zerolengtharray.cocci
new file mode 100644
index 000000000000..50d8b00716ae
--- /dev/null
+++ b/devtools/cocci/zerolengtharray.cocci
@@ -0,0 +1,17 @@
+//
+// Replace all older style of one-element or zero length arrays
+// with current flexible member arraya
+//
+
+@@
+identifier S, member, array;
+type T1, T2;
+@@
+
+struct S {
+ ...
+ T1 member;
+ T2 array[
+- 0
+ ];
+};
--
2.34.1
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC 2/2] treewide: replace zero-length array with flex array
2022-02-15 23:00 [RFC 0/2] Eliminate zero length arrays in DPDK Stephen Hemminger
2022-02-15 23:00 ` [RFC 1/2] devtools: add script to check for zero length array Stephen Hemminger
@ 2022-02-15 23:00 ` Stephen Hemminger
2022-02-16 9:27 ` [RFC 0/2] Eliminate zero length arrays in DPDK Morten Brørup
` (2 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Stephen Hemminger @ 2022-02-15 23:00 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Cristian Dumitrescu, Hemant Agrawal,
Sachin Saxena, Nithin Dabilpuram, Kiran Kumar K,
Sunil Kumar Kori, Satha Rao, Matan Azrad, Viacheslav Ovsiienko,
Gagandeep Singh, Fan Zhang, Pablo de Lara, Jay Zhou,
Rahul Lakkireddy, John Daley, Hyong Youb Kim, Ziyang Xuan,
Xiaoyun Wang, Guoyang Zhou, Heinrich Kuhn, Maxime Coquelin,
Chenbo Xia, Ori Kam, Konstantin Ananyev, Akhil Goyal,
Bernard Iremonger, Vladimir Medvedkin
Apply the coccinelle strip to find/fix use of zero length
arrays at end of structures.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
app/test/test_table_tables.c | 2 +-
drivers/bus/dpaa/include/netcfg.h | 4 ++--
drivers/common/cnxk/roc_se.h | 2 +-
drivers/common/dpaax/caamflib/desc/ipsec.h | 2 +-
drivers/common/dpaax/dpaax_iova_table.h | 2 +-
drivers/common/mlx5/mlx5_prm.h | 8 ++++----
drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 2 +-
drivers/crypto/ipsec_mb/ipsec_mb_private.h | 4 ++--
drivers/crypto/virtio/virtio_ring.h | 4 ++--
drivers/crypto/virtio/virtqueue.h | 2 +-
drivers/net/cxgbe/clip_tbl.h | 2 +-
drivers/net/cxgbe/l2t.h | 2 +-
drivers/net/cxgbe/mps_tcam.h | 2 +-
drivers/net/cxgbe/smt.h | 2 +-
drivers/net/enic/base/vnic_devcmd.h | 4 ++--
drivers/net/hinic/hinic_pmd_tx.h | 2 +-
drivers/net/nfp/nfpcore/nfp_nsp.h | 2 +-
drivers/net/virtio/virtio_ring.h | 4 ++--
drivers/net/virtio/virtio_user/vhost_kernel.c | 2 +-
drivers/net/virtio/virtio_user/vhost_vdpa.c | 2 +-
drivers/net/virtio/virtqueue.h | 2 +-
drivers/regex/mlx5/mlx5_rxp.h | 2 +-
examples/ip_reassembly/main.c | 2 +-
lib/cryptodev/cryptodev_pmd.h | 2 +-
lib/cryptodev/rte_cryptodev.h | 2 +-
lib/ip_frag/ip_reassembly.h | 2 +-
lib/ipsec/sa.h | 2 +-
lib/rib/rte_rib.c | 2 +-
lib/rib/rte_rib6.c | 2 +-
lib/table/rte_swx_table_learner.c | 2 +-
lib/table/rte_table_hash_key16.c | 4 ++--
lib/table/rte_table_hash_key32.c | 4 ++--
lib/table/rte_table_hash_key8.c | 4 ++--
lib/vhost/rte_vhost.h | 4 ++--
34 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/app/test/test_table_tables.c b/app/test/test_table_tables.c
index d5c5a426bc7c..e1b80b5aa208 100644
--- a/app/test/test_table_tables.c
+++ b/app/test/test_table_tables.c
@@ -53,7 +53,7 @@ struct rte_bucket_4_8 {
uint64_t next_valid;
uint64_t key[4];
/* Cache line 1 */
- uint8_t data[0];
+ uint8_t data[];
};
#if RTE_TABLE_HASH_LRU_STRATEGY == 3
diff --git a/drivers/bus/dpaa/include/netcfg.h b/drivers/bus/dpaa/include/netcfg.h
index bb18a34e3d71..43c7e1cfe139 100644
--- a/drivers/bus/dpaa/include/netcfg.h
+++ b/drivers/bus/dpaa/include/netcfg.h
@@ -23,7 +23,7 @@ struct fm_eth_port_cfg {
struct netcfg_info {
uint8_t num_ethports;
/**< Number of ports */
- struct fm_eth_port_cfg port_cfg[0];
+ struct fm_eth_port_cfg port_cfg[];
/**< Variable structure array of size num_ethports */
};
@@ -38,7 +38,7 @@ struct interface_info {
struct netcfg_interface {
uint8_t numof_netcfg_interface;
uint8_t numof_fman_enabled_macless;
- struct interface_info interface_info[0];
+ struct interface_info interface_info[];
};
/* pcd_file: FMC netpcd XML ("policy") file, that contains PCD information.
diff --git a/drivers/common/cnxk/roc_se.h b/drivers/common/cnxk/roc_se.h
index 145a1825bd60..a1d476a86de7 100644
--- a/drivers/common/cnxk/roc_se.h
+++ b/drivers/common/cnxk/roc_se.h
@@ -246,7 +246,7 @@ struct roc_se_buf_ptr {
/* IOV Pointer */
struct roc_se_iov_ptr {
int buf_cnt;
- struct roc_se_buf_ptr bufs[0];
+ struct roc_se_buf_ptr bufs[];
};
struct roc_se_fc_params {
diff --git a/drivers/common/dpaax/caamflib/desc/ipsec.h b/drivers/common/dpaax/caamflib/desc/ipsec.h
index 668d21649dc3..a4e511d3c370 100644
--- a/drivers/common/dpaax/caamflib/desc/ipsec.h
+++ b/drivers/common/dpaax/caamflib/desc/ipsec.h
@@ -350,7 +350,7 @@ struct ipsec_encap_pdb {
};
uint32_t spi;
uint32_t ip_hdr_len;
- uint8_t ip_hdr[0];
+ uint8_t ip_hdr[];
};
static inline unsigned int
diff --git a/drivers/common/dpaax/dpaax_iova_table.h b/drivers/common/dpaax/dpaax_iova_table.h
index b1f2300c52b3..9a18eafca024 100644
--- a/drivers/common/dpaax/dpaax_iova_table.h
+++ b/drivers/common/dpaax/dpaax_iova_table.h
@@ -32,7 +32,7 @@ struct dpaax_iovat_element {
struct dpaax_iova_table {
unsigned int count; /**< No. of blocks of contiguous physical pages */
- struct dpaax_iovat_element entries[0];
+ struct dpaax_iovat_element entries[];
};
/* Pointer to the table, which is common for DPAA/DPAA2 and only a single
diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index 495b63191aba..01a6c50c5245 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -3433,7 +3433,7 @@ struct mlx5_ifc_qpc_pas_list_bits {
#endif
struct mlx5_ifc_qpc_extension_and_pas_list_bits {
struct mlx5_ifc_qpc_extension_bits qpc_data_extension;
- u8 pas[0][0x40];
+ u8 pas[][0x40];
};
@@ -3657,7 +3657,7 @@ struct mlx5_ifc_query_qp_out_bits {
u8 reserved_at_a0[0x20];
struct mlx5_ifc_qpc_bits qpc;
u8 reserved_at_800[0x80];
- u8 pas[0][0x40];
+ u8 pas[][0x40];
};
#ifdef PEDANTIC
#pragma GCC diagnostic error "-Wpedantic"
@@ -3697,7 +3697,7 @@ struct mlx5_ifc_access_register_out_bits {
u8 reserved_at_8[0x18];
u8 syndrome[0x20];
u8 reserved_at_40[0x40];
- u8 register_data[0][0x20];
+ u8 register_data[][0x20];
};
struct mlx5_ifc_access_register_in_bits {
@@ -3708,7 +3708,7 @@ struct mlx5_ifc_access_register_in_bits {
u8 reserved_at_40[0x10];
u8 register_id[0x10];
u8 argument[0x20];
- u8 register_data[0][0x20];
+ u8 register_data[][0x20];
};
#ifdef PEDANTIC
#pragma GCC diagnostic error "-Wpedantic"
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h b/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
index 3094778a7ac7..d12482078754 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
@@ -128,7 +128,7 @@ struct sec_flc_desc {
struct ctxt_priv {
struct rte_mempool *fle_pool; /* per device memory pool for FLE */
- struct sec_flc_desc flc_desc[0];
+ struct sec_flc_desc flc_desc[];
};
enum dpaa2_sec_op_type {
diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_private.h b/drivers/crypto/ipsec_mb/ipsec_mb_private.h
index e53101acf178..e2c240dfc05d 100644
--- a/drivers/crypto/ipsec_mb/ipsec_mb_private.h
+++ b/drivers/crypto/ipsec_mb/ipsec_mb_private.h
@@ -120,7 +120,7 @@ struct ipsec_mb_dev_private {
/**< PMD type */
uint32_t max_nb_queue_pairs;
/**< Max number of queue pairs supported by device */
- __extension__ uint8_t priv[0];
+ __extension__ uint8_t priv[];
};
/** IPSEC Multi buffer queue pair common queue pair data for all PMDs */
@@ -147,7 +147,7 @@ struct ipsec_mb_qp {
/* Multi buffer manager */
const struct rte_memzone *mb_mgr_mz;
/* Shared memzone for storing mb_mgr */
- __extension__ uint8_t additional_data[0];
+ __extension__ uint8_t additional_data[];
/**< Storing PMD specific additional data */
};
diff --git a/drivers/crypto/virtio/virtio_ring.h b/drivers/crypto/virtio/virtio_ring.h
index ee3067456688..55839279fd89 100644
--- a/drivers/crypto/virtio/virtio_ring.h
+++ b/drivers/crypto/virtio/virtio_ring.h
@@ -40,7 +40,7 @@ struct vring_desc {
struct vring_avail {
uint16_t flags;
uint16_t idx;
- uint16_t ring[0];
+ uint16_t ring[];
};
/* id is a 16bit index. uint32_t is used here for ids for padding reasons. */
@@ -54,7 +54,7 @@ struct vring_used_elem {
struct vring_used {
uint16_t flags;
volatile uint16_t idx;
- struct vring_used_elem ring[0];
+ struct vring_used_elem ring[];
};
struct vring {
diff --git a/drivers/crypto/virtio/virtqueue.h b/drivers/crypto/virtio/virtqueue.h
index c96ca629921b..cb08bea94f1c 100644
--- a/drivers/crypto/virtio/virtqueue.h
+++ b/drivers/crypto/virtio/virtqueue.h
@@ -88,7 +88,7 @@ struct virtqueue {
uint16_t *notify_addr;
- struct vq_desc_extra vq_descx[0];
+ struct vq_desc_extra vq_descx[];
};
/**
diff --git a/drivers/net/cxgbe/clip_tbl.h b/drivers/net/cxgbe/clip_tbl.h
index d7689f4b7a3a..3b2be6645f2e 100644
--- a/drivers/net/cxgbe/clip_tbl.h
+++ b/drivers/net/cxgbe/clip_tbl.h
@@ -20,7 +20,7 @@ struct clip_tbl {
unsigned int clipt_start; /* start index of CLIP table */
unsigned int clipt_size; /* size of CLIP table */
rte_rwlock_t lock; /* table rw lock */
- struct clip_entry cl_list[0]; /* MUST BE LAST */
+ struct clip_entry cl_list[]; /* MUST BE LAST */
};
struct clip_tbl *t4_init_clip_tbl(unsigned int clipt_start,
diff --git a/drivers/net/cxgbe/l2t.h b/drivers/net/cxgbe/l2t.h
index 9845c9f98124..e4c0ebedec9e 100644
--- a/drivers/net/cxgbe/l2t.h
+++ b/drivers/net/cxgbe/l2t.h
@@ -37,7 +37,7 @@ struct l2t_data {
unsigned int l2t_start; /* start index of our piece of the L2T */
unsigned int l2t_size; /* number of entries in l2tab */
rte_rwlock_t lock; /* table rw lock */
- struct l2t_entry l2tab[0]; /* MUST BE LAST */
+ struct l2t_entry l2tab[]; /* MUST BE LAST */
};
#define L2T_LPBK true
diff --git a/drivers/net/cxgbe/mps_tcam.h b/drivers/net/cxgbe/mps_tcam.h
index a359f52442fa..363786bd387f 100644
--- a/drivers/net/cxgbe/mps_tcam.h
+++ b/drivers/net/cxgbe/mps_tcam.h
@@ -41,7 +41,7 @@ struct mpstcam_table {
* free_idx cannot alone determine
* if the table is full
*/
- struct mps_tcam_entry entry[0];
+ struct mps_tcam_entry entry[];
};
struct mpstcam_table *t4_init_mpstcam(struct adapter *adap);
diff --git a/drivers/net/cxgbe/smt.h b/drivers/net/cxgbe/smt.h
index e6e8aea964e1..81ee919544eb 100644
--- a/drivers/net/cxgbe/smt.h
+++ b/drivers/net/cxgbe/smt.h
@@ -31,7 +31,7 @@ struct smt_data {
unsigned int smt_size;
unsigned int smt_start;
rte_rwlock_t lock;
- struct smt_entry smtab[0];
+ struct smt_entry smtab[];
};
struct smt_data *t4_init_smt(u32 smt_start_idx, u32 smt_size);
diff --git a/drivers/net/enic/base/vnic_devcmd.h b/drivers/net/enic/base/vnic_devcmd.h
index 3157bc8cb5ee..f91cc3078d63 100644
--- a/drivers/net/enic/base/vnic_devcmd.h
+++ b/drivers/net/enic/base/vnic_devcmd.h
@@ -765,7 +765,7 @@ struct vnic_devcmd_notify {
struct vnic_devcmd_provinfo {
uint8_t oui[3];
uint8_t type;
- uint8_t data[0];
+ uint8_t data[];
};
/*
@@ -997,7 +997,7 @@ enum {
struct filter_tlv {
uint32_t type;
uint32_t length;
- uint32_t val[0];
+ uint32_t val[];
};
/* Data for CMD_ADD_FILTER is 2 TLV and filter + action structs */
diff --git a/drivers/net/hinic/hinic_pmd_tx.h b/drivers/net/hinic/hinic_pmd_tx.h
index a3ec6299fbe1..152f7abc53f4 100644
--- a/drivers/net/hinic/hinic_pmd_tx.h
+++ b/drivers/net/hinic/hinic_pmd_tx.h
@@ -81,7 +81,7 @@ struct hinic_sq_wqe {
struct hinic_sq_task task;
/* sq sge section start address, 1~127 sges */
- struct hinic_sq_bufdesc buf_descs[0];
+ struct hinic_sq_bufdesc buf_descs[];
};
struct hinic_txq_stats {
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp.h b/drivers/net/nfp/nfpcore/nfp_nsp.h
index e74cdeb19100..2184c15b4c0b 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp.h
+++ b/drivers/net/nfp/nfpcore/nfp_nsp.h
@@ -224,7 +224,7 @@ struct nfp_eth_table {
int is_split;
unsigned int fec_modes_supported;
- } ports[0];
+ } ports[];
};
struct nfp_eth_table *nfp_eth_read_ports(struct nfp_cpp *cpp);
diff --git a/drivers/net/virtio/virtio_ring.h b/drivers/net/virtio/virtio_ring.h
index 17a56b0a7341..e848c0b73b3d 100644
--- a/drivers/net/virtio/virtio_ring.h
+++ b/drivers/net/virtio/virtio_ring.h
@@ -46,7 +46,7 @@ struct vring_desc {
struct vring_avail {
uint16_t flags;
uint16_t idx;
- uint16_t ring[0];
+ uint16_t ring[];
};
/* id is a 16bit index. uint32_t is used here for ids for padding reasons. */
@@ -60,7 +60,7 @@ struct vring_used_elem {
struct vring_used {
uint16_t flags;
uint16_t idx;
- struct vring_used_elem ring[0];
+ struct vring_used_elem ring[];
};
/* For support of packed virtqueues in Virtio 1.1 the format of descriptors
diff --git a/drivers/net/virtio/virtio_user/vhost_kernel.c b/drivers/net/virtio/virtio_user/vhost_kernel.c
index 202a8cdee1ca..d9eeadcbf25c 100644
--- a/drivers/net/virtio/virtio_user/vhost_kernel.c
+++ b/drivers/net/virtio/virtio_user/vhost_kernel.c
@@ -22,7 +22,7 @@ struct vhost_kernel_data {
struct vhost_memory_kernel {
uint32_t nregions;
uint32_t padding;
- struct vhost_memory_region regions[0];
+ struct vhost_memory_region regions[];
};
/* vhost kernel ioctls */
diff --git a/drivers/net/virtio/virtio_user/vhost_vdpa.c b/drivers/net/virtio/virtio_user/vhost_vdpa.c
index 82f25a8674b0..bd13fe44b4c1 100644
--- a/drivers/net/virtio/virtio_user/vhost_vdpa.c
+++ b/drivers/net/virtio/virtio_user/vhost_vdpa.c
@@ -70,7 +70,7 @@ struct vhost_iotlb_msg {
struct vhost_vdpa_config {
uint32_t off;
uint32_t len;
- uint8_t buf[0];
+ uint8_t buf[];
};
struct vhost_msg {
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 99c68cf62231..d100ed876209 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -309,7 +309,7 @@ struct virtqueue {
uint16_t *notify_addr;
struct rte_mbuf **sw_ring; /**< RX software ring. */
- struct vq_desc_extra vq_descx[0];
+ struct vq_desc_extra vq_descx[];
};
/* If multiqueue is provided by host, then we support it. */
diff --git a/drivers/regex/mlx5/mlx5_rxp.h b/drivers/regex/mlx5/mlx5_rxp.h
index 315e3b4ca3b2..6076904fc3a1 100644
--- a/drivers/regex/mlx5/mlx5_rxp.h
+++ b/drivers/regex/mlx5/mlx5_rxp.h
@@ -64,7 +64,7 @@ struct mlx5_rxp_match_tuple {
struct mlx5_rxp_response {
struct mlx5_rxp_response_desc header;
- struct mlx5_rxp_match_tuple matches[0];
+ struct mlx5_rxp_match_tuple matches[];
};
#define MLX5_RXP_MAX_MATCHES 254
diff --git a/examples/ip_reassembly/main.c b/examples/ip_reassembly/main.c
index 6e4c11c3c7e0..3ebf895aa01d 100644
--- a/examples/ip_reassembly/main.c
+++ b/examples/ip_reassembly/main.c
@@ -126,7 +126,7 @@ struct mbuf_table {
uint32_t len;
uint32_t head;
uint32_t tail;
- struct rte_mbuf *m_table[0];
+ struct rte_mbuf *m_table[];
};
struct rx_queue {
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index d91902f6e0fe..09def60d3118 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -637,7 +637,7 @@ RTE_STD_C11 struct rte_cryptodev_asym_session {
uint16_t user_data_sz;
/**< Session user data will be placed after sess_data */
uint8_t padding[3];
- uint8_t sess_private_data[0];
+ uint8_t sess_private_data[];
};
#endif /* _CRYPTODEV_PMD_H_ */
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 19e2e7028709..6f919ff2c41e 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -914,7 +914,7 @@ struct rte_cryptodev_sym_session {
__extension__ struct {
void *data;
uint16_t refcnt;
- } sess_data[0];
+ } sess_data[];
/**< Driver specific session material, variable size */
};
diff --git a/lib/ip_frag/ip_reassembly.h b/lib/ip_frag/ip_reassembly.h
index 416fb66dd485..ef9d8c0d75ad 100644
--- a/lib/ip_frag/ip_reassembly.h
+++ b/lib/ip_frag/ip_reassembly.h
@@ -83,7 +83,7 @@ struct rte_ip_frag_tbl {
struct ip_frag_pkt *last; /* last used entry. */
struct ip_pkt_list lru; /* LRU list for table entries. */
struct ip_frag_tbl_stat stat; /* statistics counters. */
- __extension__ struct ip_frag_pkt pkt[0]; /* hash table. */
+ __extension__ struct ip_frag_pkt pkt[]; /* hash table. */
};
#endif /* _IP_REASSEMBLY_H_ */
diff --git a/lib/ipsec/sa.h b/lib/ipsec/sa.h
index 7503587b5004..15bb7e9323fd 100644
--- a/lib/ipsec/sa.h
+++ b/lib/ipsec/sa.h
@@ -60,7 +60,7 @@ union sym_op_data {
struct replay_sqn {
rte_rwlock_t rwl;
uint64_t sqn;
- __extension__ uint64_t window[0];
+ __extension__ uint64_t window[];
};
/*IPSEC SA supported algorithms */
diff --git a/lib/rib/rte_rib.c b/lib/rib/rte_rib.c
index 6c29e1c49ab2..e8bd027c20e2 100644
--- a/lib/rib/rte_rib.c
+++ b/lib/rib/rte_rib.c
@@ -37,7 +37,7 @@ struct rte_rib_node {
uint8_t depth;
uint8_t flag;
uint64_t nh;
- __extension__ uint64_t ext[0];
+ __extension__ uint64_t ext[];
};
struct rte_rib {
diff --git a/lib/rib/rte_rib6.c b/lib/rib/rte_rib6.c
index 70405113b419..dc52e0e29cec 100644
--- a/lib/rib/rte_rib6.c
+++ b/lib/rib/rte_rib6.c
@@ -36,7 +36,7 @@ struct rte_rib6_node {
uint8_t ip[RTE_RIB6_IPV6_ADDR_SIZE];
uint8_t depth;
uint8_t flag;
- __extension__ uint64_t ext[0];
+ __extension__ uint64_t ext[];
};
struct rte_rib6 {
diff --git a/lib/table/rte_swx_table_learner.c b/lib/table/rte_swx_table_learner.c
index c3c840ff0662..3f6acfd45574 100644
--- a/lib/table/rte_swx_table_learner.c
+++ b/lib/table/rte_swx_table_learner.c
@@ -238,7 +238,7 @@ struct table_bucket {
uint32_t time[TABLE_KEYS_PER_BUCKET];
uint32_t sig[TABLE_KEYS_PER_BUCKET];
uint8_t pad[TABLE_BUCKET_PAD_SIZE];
- uint8_t key[0];
+ uint8_t key[];
};
struct table_params {
diff --git a/lib/table/rte_table_hash_key16.c b/lib/table/rte_table_hash_key16.c
index c4384b114dc5..246d23d4d360 100644
--- a/lib/table/rte_table_hash_key16.c
+++ b/lib/table/rte_table_hash_key16.c
@@ -45,7 +45,7 @@ struct rte_bucket_4_16 {
uint64_t key[4][2];
/* Cache line 2 */
- uint8_t data[0];
+ uint8_t data[];
};
#else
struct rte_bucket_4_16 {
@@ -60,7 +60,7 @@ struct rte_bucket_4_16 {
uint64_t key[4][2];
/* Cache line 2 */
- uint8_t data[0];
+ uint8_t data[];
};
#endif
diff --git a/lib/table/rte_table_hash_key32.c b/lib/table/rte_table_hash_key32.c
index 3e0031fe1e21..c154444ea63d 100644
--- a/lib/table/rte_table_hash_key32.c
+++ b/lib/table/rte_table_hash_key32.c
@@ -45,7 +45,7 @@ struct rte_bucket_4_32 {
uint64_t key[4][4];
/* Cache line 3 */
- uint8_t data[0];
+ uint8_t data[];
};
#else
struct rte_bucket_4_32 {
@@ -60,7 +60,7 @@ struct rte_bucket_4_32 {
uint64_t key[4][4];
/* Cache line 3 */
- uint8_t data[0];
+ uint8_t data[];
};
#endif
diff --git a/lib/table/rte_table_hash_key8.c b/lib/table/rte_table_hash_key8.c
index 34e3ed1af914..4c14dfcbbac7 100644
--- a/lib/table/rte_table_hash_key8.c
+++ b/lib/table/rte_table_hash_key8.c
@@ -42,7 +42,7 @@ struct rte_bucket_4_8 {
uint64_t key[4];
/* Cache line 1 */
- uint8_t data[0];
+ uint8_t data[];
};
#else
struct rte_bucket_4_8 {
@@ -56,7 +56,7 @@ struct rte_bucket_4_8 {
uint64_t key[4];
/* Cache line 1 */
- uint8_t data[0];
+ uint8_t data[];
};
#endif
diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
index c733f857c62b..99be18ceef49 100644
--- a/lib/vhost/rte_vhost.h
+++ b/lib/vhost/rte_vhost.h
@@ -154,7 +154,7 @@ struct rte_vhost_inflight_info_split {
uint16_t desc_num;
uint16_t last_inflight_io;
uint16_t used_idx;
- struct rte_vhost_inflight_desc_split desc[0];
+ struct rte_vhost_inflight_desc_split desc[];
};
struct rte_vhost_inflight_desc_packed {
@@ -181,7 +181,7 @@ struct rte_vhost_inflight_info_packed {
uint8_t used_wrap_counter;
uint8_t old_used_wrap_counter;
uint8_t padding[7];
- struct rte_vhost_inflight_desc_packed desc[0];
+ struct rte_vhost_inflight_desc_packed desc[];
};
struct rte_vhost_resubmit_desc {
--
2.34.1
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-15 23:00 [RFC 0/2] Eliminate zero length arrays in DPDK Stephen Hemminger
2022-02-15 23:00 ` [RFC 1/2] devtools: add script to check for zero length array Stephen Hemminger
2022-02-15 23:00 ` [RFC 2/2] treewide: replace zero-length array with flex array Stephen Hemminger
@ 2022-02-16 9:27 ` Morten Brørup
2022-02-16 9:33 ` Bruce Richardson
2022-02-17 8:09 ` Tyler Retzlaff
4 siblings, 0 replies; 14+ messages in thread
From: Morten Brørup @ 2022-02-16 9:27 UTC (permalink / raw)
To: Stephen Hemminger, dev
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, 16 February 2022 00.01
>
> Yet another case of applying Linux kernel best practices
> to DPDK. Flexible arrays are supported by Clang, GCC and
> Microsoft compilers (part of C99).
>
> Stephen Hemminger (2):
> devtools: add script to check for zero length array
> treewide: replace zero-length array with flex array
>
> app/test/test_table_tables.c | 2 +-
> devtools/cocci/zerolengtharray.cocci | 17 +++++++++++++++++
> drivers/bus/dpaa/include/netcfg.h | 4 ++--
> drivers/common/cnxk/roc_se.h | 2 +-
> drivers/common/dpaax/caamflib/desc/ipsec.h | 2 +-
> drivers/common/dpaax/dpaax_iova_table.h | 2 +-
> drivers/common/mlx5/mlx5_prm.h | 8 ++++----
> drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 2 +-
> drivers/crypto/ipsec_mb/ipsec_mb_private.h | 4 ++--
> drivers/crypto/virtio/virtio_ring.h | 4 ++--
> drivers/crypto/virtio/virtqueue.h | 2 +-
> drivers/net/cxgbe/clip_tbl.h | 2 +-
> drivers/net/cxgbe/l2t.h | 2 +-
> drivers/net/cxgbe/mps_tcam.h | 2 +-
> drivers/net/cxgbe/smt.h | 2 +-
> drivers/net/enic/base/vnic_devcmd.h | 4 ++--
> drivers/net/hinic/hinic_pmd_tx.h | 2 +-
> drivers/net/nfp/nfpcore/nfp_nsp.h | 2 +-
> drivers/net/virtio/virtio_ring.h | 4 ++--
> drivers/net/virtio/virtio_user/vhost_kernel.c | 2 +-
> drivers/net/virtio/virtio_user/vhost_vdpa.c | 2 +-
> drivers/net/virtio/virtqueue.h | 2 +-
> drivers/regex/mlx5/mlx5_rxp.h | 2 +-
> examples/ip_reassembly/main.c | 2 +-
> lib/cryptodev/cryptodev_pmd.h | 2 +-
> lib/cryptodev/rte_cryptodev.h | 2 +-
> lib/ip_frag/ip_reassembly.h | 2 +-
> lib/ipsec/sa.h | 2 +-
> lib/rib/rte_rib.c | 2 +-
> lib/rib/rte_rib6.c | 2 +-
> lib/table/rte_swx_table_learner.c | 2 +-
> lib/table/rte_table_hash_key16.c | 4 ++--
> lib/table/rte_table_hash_key32.c | 4 ++--
> lib/table/rte_table_hash_key8.c | 4 ++--
> lib/vhost/rte_vhost.h | 4 ++--
> 35 files changed, 63 insertions(+), 46 deletions(-)
> create mode 100644 devtools/cocci/zerolengtharray.cocci
>
> --
> 2.34.1
Thank you! We must all appreciate the DPDK housekeeping efforts, where it DPDK gets some real love, and not just added support for new bells and whistles in fancy NICs. :-)
Series-Acked-By: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-15 23:00 [RFC 0/2] Eliminate zero length arrays in DPDK Stephen Hemminger
` (2 preceding siblings ...)
2022-02-16 9:27 ` [RFC 0/2] Eliminate zero length arrays in DPDK Morten Brørup
@ 2022-02-16 9:33 ` Bruce Richardson
2022-02-16 10:05 ` Morten Brørup
2022-02-16 18:56 ` Stephen Hemminger
2022-02-17 8:09 ` Tyler Retzlaff
4 siblings, 2 replies; 14+ messages in thread
From: Bruce Richardson @ 2022-02-16 9:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote:
> Yet another case of applying Linux kernel best practices
> to DPDK. Flexible arrays are supported by Clang, GCC and
> Microsoft compilers (part of C99).
>
Do we need to start explicitly stating that DPDK uses C99 features, and
adding -std=c99 to our build flags? Are we also requiring that applications
are compiled with c99 features to use this (I would hope that they are, but
I'm not sure we can mandate it).
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-16 9:33 ` Bruce Richardson
@ 2022-02-16 10:05 ` Morten Brørup
2022-02-16 10:10 ` Bruce Richardson
2022-02-16 18:56 ` Stephen Hemminger
1 sibling, 1 reply; 14+ messages in thread
From: Morten Brørup @ 2022-02-16 10:05 UTC (permalink / raw)
To: Bruce Richardson, Stephen Hemminger; +Cc: dev
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Wednesday, 16 February 2022 10.33
>
> On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote:
> > Yet another case of applying Linux kernel best practices
> > to DPDK. Flexible arrays are supported by Clang, GCC and
> > Microsoft compilers (part of C99).
> >
> Do we need to start explicitly stating that DPDK uses C99 features, and
> adding -std=c99 to our build flags? Are we also requiring that
> applications
> are compiled with c99 features to use this (I would hope that they are,
> but
> I'm not sure we can mandate it).
No to -std=c99. It's >= C99 for applications; we should not prevent them from using a newer C standard.
Adding a note about the C standard version to the DPDK requirements documentation would be very nice. It only mentions a certain compiler version required. But I think that documenting the detailed build and runtime requirements (and why they are that way) is another task.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-16 10:05 ` Morten Brørup
@ 2022-02-16 10:10 ` Bruce Richardson
2022-02-17 7:41 ` Tyler Retzlaff
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Richardson @ 2022-02-16 10:10 UTC (permalink / raw)
To: Morten Brørup; +Cc: Stephen Hemminger, dev
On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 16 February 2022 10.33
> >
> > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote:
> > > Yet another case of applying Linux kernel best practices
> > > to DPDK. Flexible arrays are supported by Clang, GCC and
> > > Microsoft compilers (part of C99).
> > >
> > Do we need to start explicitly stating that DPDK uses C99 features, and
> > adding -std=c99 to our build flags? Are we also requiring that
> > applications
> > are compiled with c99 features to use this (I would hope that they are,
> > but
> > I'm not sure we can mandate it).
>
> No to -std=c99. It's >= C99 for applications; we should not prevent them from using a newer C standard.
Yes. For build flags, I was referring only to having it in the cflags for the
build of DPDK itself, not for apps. We definitely need to minimise the
build flags we expose to apps.
>
> Adding a note about the C standard version to the DPDK requirements
> documentation would be very nice. It only mentions a certain compiler
> version required. But I think that documenting the detailed build and
> runtime requirements (and why they are that way) is another task.
>
Sure, we should do that. I am just wanting to be sure that if we specify a
minimum of C99, we won't get complaints back from those with legacy
codebasees which only support C89/C90. I am therefore wondering if we need
to have our public headers C90-compliant?
/Bruce
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-16 9:33 ` Bruce Richardson
2022-02-16 10:05 ` Morten Brørup
@ 2022-02-16 18:56 ` Stephen Hemminger
1 sibling, 0 replies; 14+ messages in thread
From: Stephen Hemminger @ 2022-02-16 18:56 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
On Wed, 16 Feb 2022 09:33:02 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:
> On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote:
> > Yet another case of applying Linux kernel best practices
> > to DPDK. Flexible arrays are supported by Clang, GCC and
> > Microsoft compilers (part of C99).
> >
> Do we need to start explicitly stating that DPDK uses C99 features, and
> adding -std=c99 to our build flags? Are we also requiring that applications
> are compiled with c99 features to use this (I would hope that they are, but
> I'm not sure we can mandate it).
There are already many uses of flex array in DPDK. This is nothing new.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-16 10:10 ` Bruce Richardson
@ 2022-02-17 7:41 ` Tyler Retzlaff
2022-02-24 21:51 ` Morten Brørup
0 siblings, 1 reply; 14+ messages in thread
From: Tyler Retzlaff @ 2022-02-17 7:41 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Morten Brørup, Stephen Hemminger, dev
On Wed, Feb 16, 2022 at 10:10:01AM +0000, Bruce Richardson wrote:
> On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Wednesday, 16 February 2022 10.33
> > >
> > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote:
> > > > Yet another case of applying Linux kernel best practices
> > > > to DPDK. Flexible arrays are supported by Clang, GCC and
> > > > Microsoft compilers (part of C99).
> > > >
> > > Do we need to start explicitly stating that DPDK uses C99 features, and
> > > adding -std=c99 to our build flags? Are we also requiring that
> > > applications
> > > are compiled with c99 features to use this (I would hope that they are,
> > > but
> > > I'm not sure we can mandate it).
> >
> > No to -std=c99. It's >= C99 for applications; we should not prevent them from using a newer C standard.
>
> Yes. For build flags, I was referring only to having it in the cflags for the
> build of DPDK itself, not for apps. We definitely need to minimise the
> build flags we expose to apps.
>
> >
> > Adding a note about the C standard version to the DPDK requirements
> > documentation would be very nice. It only mentions a certain compiler
> > version required. But I think that documenting the detailed build and
> > runtime requirements (and why they are that way) is another task.
> >
> Sure, we should do that. I am just wanting to be sure that if we specify a
> minimum of C99, we won't get complaints back from those with legacy
> codebasees which only support C89/C90. I am therefore wondering if we need
> to have our public headers C90-compliant?
this seems to be the real question. what "minimum" C standard should be
documented as required to consume dpdk. we can obviously use any standard
we wish to build/provide binaries. similarly we ought to document a
minimum C++ standard for consumption.
i would advocate for C99 however before setting that in stone it is fair
to ask if there are any consumers using < C99.
we may also want to consider that the minimum required may differ
depending on the platform/port. though most differences in public interface
i would hope could be trivially abstracted though.
ty
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-15 23:00 [RFC 0/2] Eliminate zero length arrays in DPDK Stephen Hemminger
` (3 preceding siblings ...)
2022-02-16 9:33 ` Bruce Richardson
@ 2022-02-17 8:09 ` Tyler Retzlaff
4 siblings, 0 replies; 14+ messages in thread
From: Tyler Retzlaff @ 2022-02-17 8:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote:
> Yet another case of applying Linux kernel best practices
> to DPDK. Flexible arrays are supported by Clang, GCC and
> Microsoft compilers (part of C99).
Series-Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
subject to the outcome of documenting C99 compiler as a minimum
requirement.
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-17 7:41 ` Tyler Retzlaff
@ 2022-02-24 21:51 ` Morten Brørup
2022-02-24 23:03 ` Stephen Hemminger
0 siblings, 1 reply; 14+ messages in thread
From: Morten Brørup @ 2022-02-24 21:51 UTC (permalink / raw)
To: Tyler Retzlaff, Bruce Richardson; +Cc: Stephen Hemminger, dev
> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Thursday, 17 February 2022 08.42
>
> On Wed, Feb 16, 2022 at 10:10:01AM +0000, Bruce Richardson wrote:
> > On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote:
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Wednesday, 16 February 2022 10.33
> > > >
> > > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger
> wrote:
> > > > > Yet another case of applying Linux kernel best practices
> > > > > to DPDK. Flexible arrays are supported by Clang, GCC and
> > > > > Microsoft compilers (part of C99).
> > > > >
> > > > Do we need to start explicitly stating that DPDK uses C99
> features, and
> > > > adding -std=c99 to our build flags? Are we also requiring that
> > > > applications
> > > > are compiled with c99 features to use this (I would hope that
> they are,
> > > > but
> > > > I'm not sure we can mandate it).
> > >
> > > No to -std=c99. It's >= C99 for applications; we should not prevent
> them from using a newer C standard.
> >
> > Yes. For build flags, I was referring only to having it in the cflags
> for the
> > build of DPDK itself, not for apps. We definitely need to minimise
> the
> > build flags we expose to apps.
> >
> > >
> > > Adding a note about the C standard version to the DPDK requirements
> > > documentation would be very nice. It only mentions a certain
> compiler
> > > version required. But I think that documenting the detailed build
> and
> > > runtime requirements (and why they are that way) is another task.
> > >
> > Sure, we should do that. I am just wanting to be sure that if we
> specify a
> > minimum of C99, we won't get complaints back from those with legacy
> > codebasees which only support C89/C90. I am therefore wondering if we
> need
> > to have our public headers C90-compliant?
>
> this seems to be the real question. what "minimum" C standard should be
> documented as required to consume dpdk. we can obviously use any
> standard
> we wish to build/provide binaries. similarly we ought to document a
> minimum C++ standard for consumption.
>
> i would advocate for C99 however before setting that in stone it is
> fair
> to ask if there are any consumers using < C99.
>
> we may also want to consider that the minimum required may differ
> depending on the platform/port. though most differences in public
> interface
> i would hope could be trivially abstracted though.
>
> ty
Just read that the Linux kernel is moving towards C11, or at minimum C99, for version 5.18:
https://lwn.net/SubscriberLink/885941/01fdc39df2ecc25f/
Let's be bold and push for the same for DPDK! :-)
-Morten
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-24 21:51 ` Morten Brørup
@ 2022-02-24 23:03 ` Stephen Hemminger
0 siblings, 0 replies; 14+ messages in thread
From: Stephen Hemminger @ 2022-02-24 23:03 UTC (permalink / raw)
To: Morten Brørup; +Cc: Tyler Retzlaff, Bruce Richardson, dev
On Thu, 24 Feb 2022 22:51:31 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Thursday, 17 February 2022 08.42
> >
> > On Wed, Feb 16, 2022 at 10:10:01AM +0000, Bruce Richardson wrote:
> > > On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Wednesday, 16 February 2022 10.33
> > > > >
> > > > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger
> > wrote:
> > > > > > Yet another case of applying Linux kernel best practices
> > > > > > to DPDK. Flexible arrays are supported by Clang, GCC and
> > > > > > Microsoft compilers (part of C99).
> > > > > >
> > > > > Do we need to start explicitly stating that DPDK uses C99
> > features, and
> > > > > adding -std=c99 to our build flags? Are we also requiring that
> > > > > applications
> > > > > are compiled with c99 features to use this (I would hope that
> > they are,
> > > > > but
> > > > > I'm not sure we can mandate it).
> > > >
> > > > No to -std=c99. It's >= C99 for applications; we should not prevent
> > them from using a newer C standard.
> > >
> > > Yes. For build flags, I was referring only to having it in the cflags
> > for the
> > > build of DPDK itself, not for apps. We definitely need to minimise
> > the
> > > build flags we expose to apps.
> > >
> > > >
> > > > Adding a note about the C standard version to the DPDK requirements
> > > > documentation would be very nice. It only mentions a certain
> > compiler
> > > > version required. But I think that documenting the detailed build
> > and
> > > > runtime requirements (and why they are that way) is another task.
> > > >
> > > Sure, we should do that. I am just wanting to be sure that if we
> > specify a
> > > minimum of C99, we won't get complaints back from those with legacy
> > > codebasees which only support C89/C90. I am therefore wondering if we
> > need
> > > to have our public headers C90-compliant?
> >
> > this seems to be the real question. what "minimum" C standard should be
> > documented as required to consume dpdk. we can obviously use any
> > standard
> > we wish to build/provide binaries. similarly we ought to document a
> > minimum C++ standard for consumption.
> >
> > i would advocate for C99 however before setting that in stone it is
> > fair
> > to ask if there are any consumers using < C99.
> >
> > we may also want to consider that the minimum required may differ
> > depending on the platform/port. though most differences in public
> > interface
> > i would hope could be trivially abstracted though.
> >
> > ty
>
> Just read that the Linux kernel is moving towards C11, or at minimum C99, for version 5.18:
> https://lwn.net/SubscriberLink/885941/01fdc39df2ecc25f/
>
> Let's be bold and push for the same for DPDK! :-)
Would be good, but still getting held back by legacy distros (RHEL)
and other compiler environments ICC, etc.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC 0/2] Eliminate zero length arrays in DPDK
2022-02-16 10:39 Morten Brørup
@ 2022-02-17 8:32 ` Tyler Retzlaff
0 siblings, 0 replies; 14+ messages in thread
From: Tyler Retzlaff @ 2022-02-17 8:32 UTC (permalink / raw)
To: Morten Brørup; +Cc: Bruce Richardson, Stephen Hemminger, dev
On Wed, Feb 16, 2022 at 11:39:30AM +0100, Morten Brørup wrote:
> My answer is at the end.Sent from a smartphone. Please pardon brevity and spelling.
> I am therefore wondering if we needto have our public headers C90-compliant?/BruceWe are publicly using C11 for atomics [1]. I'm not sure if that also implies that we are requiring C11 generally. Otherwise, I agree with your concerns about old code bases. [1]https://www.dpdk.org/blog/2021/03/26/dpdk-adopts-the-c11-memory-model
we aren't actually using C11 atomics. we are using gcc builtin atomics
that follow the C11 memory model for accessing atomics.
so strictly speaking we don't need to make the minimum a C11 compiler.
i suspect a lot of pushback would occur if we made C11 a minimum. so
for atomics i would make the suggestion that we abstract atomics to
permit C11 atomics to be used when a C11 compiler with stdatomic is
available.
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [RFC 0/2] Eliminate zero length arrays in DPDK
@ 2022-02-16 10:39 Morten Brørup
2022-02-17 8:32 ` Tyler Retzlaff
0 siblings, 1 reply; 14+ messages in thread
From: Morten Brørup @ 2022-02-16 10:39 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Stephen Hemminger, dev
[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]
My answer is at the end.Sent from a smartphone. Please pardon brevity and spelling.
-------- Oprindelig besked --------Fra: Bruce Richardson <bruce.richardson@intel.com> Dato: 16/02/2022 11.15 (GMT+01:00) Til: Morten Brørup <mb@smartsharesystems.com> Cc: Stephen Hemminger <stephen@networkplumber.org>, dev@dpdk.org Emne: Re: [RFC 0/2] Eliminate zero length arrays in DPDK On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote:> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]> > Sent: Wednesday, 16 February 2022 10.33> > > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote:> > > Yet another case of applying Linux kernel best practices> > > to DPDK. Flexible arrays are supported by Clang, GCC and> > > Microsoft compilers (part of C99).> > >> > Do we need to start explicitly stating that DPDK uses C99 features, and> > adding -std=c99 to our build flags? Are we also requiring that> > applications> > are compiled with c99 features to use this (I would hope that they are,> > but> > I'm not sure we can mandate it).> > No to -std=c99. It's >= C99 for applications; we should not prevent them from using a newer C standard.Yes. For build flags, I was referring only to having it in the cflags for thebuild of DPDK itself, not for apps. We definitely need to minimise thebuild flags we expose to apps.> > Adding a note about the C standard version to the DPDK requirements> documentation would be very nice. It only mentions a certain compiler> version required. But I think that documenting the detailed build and> runtime requirements (and why they are that way) is another task.> Sure, we should do that. I am just wanting to be sure that if we specify aminimum of C99, we won't get complaints back from those with legacycodebasees which only support C89/C90. I am therefore wondering if we needto have our public headers C90-compliant?/BruceWe are publicly using C11 for atomics [1]. I'm not sure if that also implies that we are requiring C11 generally.Otherwise, I agree with your concerns about old code bases.[1]https://www.dpdk.org/blog/2021/03/26/dpdk-adopts-the-c11-memory-model/-Morten
[-- Attachment #2: Type: text/html, Size: 3574 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2022-02-24 23:03 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-15 23:00 [RFC 0/2] Eliminate zero length arrays in DPDK Stephen Hemminger
2022-02-15 23:00 ` [RFC 1/2] devtools: add script to check for zero length array Stephen Hemminger
2022-02-15 23:00 ` [RFC 2/2] treewide: replace zero-length array with flex array Stephen Hemminger
2022-02-16 9:27 ` [RFC 0/2] Eliminate zero length arrays in DPDK Morten Brørup
2022-02-16 9:33 ` Bruce Richardson
2022-02-16 10:05 ` Morten Brørup
2022-02-16 10:10 ` Bruce Richardson
2022-02-17 7:41 ` Tyler Retzlaff
2022-02-24 21:51 ` Morten Brørup
2022-02-24 23:03 ` Stephen Hemminger
2022-02-16 18:56 ` Stephen Hemminger
2022-02-17 8:09 ` Tyler Retzlaff
2022-02-16 10:39 Morten Brørup
2022-02-17 8:32 ` Tyler Retzlaff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).