> ...
>
> 1. Some options are failing for me [1], I don't know if it requires a
> specific version of clang-format
>
I fixed these errors, and the clang-format version should be 17. I will
send them after some discussions, as I've shared below.
>
> 2. Current options are not fully aligned with coding convention, it is
> easier to see what is not compatible by running the tool on an existing
> file [2].
> we need to fix them.
>
> There are some cases that we need to discuss. First of all, I applied the
latest clang format that I created.
- In default cases for clang-format, include headers are sorted
alphabetically. It improves the readability of code, and it breaks the
codebase. These changes do not affect code maintenance because they are
only headers.
- Second question about the column width. In the definition of
.editorconfig, the column width is set as 100, but the previous commits
violate this. Here is the sample code:
struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
@@ -61,8 +61,7 @@ static const struct rte_eth_xstats_name_off
eth_dev_stats_strings[] = {
{"rx_missed_errors", offsetof(struct rte_eth_stats, imissed)},
{"rx_errors", offsetof(struct rte_eth_stats, ierrors)},
{"tx_errors", offsetof(struct rte_eth_stats, oerrors)},
- {"rx_mbuf_allocation_errors", offsetof(struct rte_eth_stats,
- rx_nombuf)},
+ {"rx_mbuf_allocation_errors", offsetof(struct rte_eth_stats,
rx_nombuf)},
};
We could use this clang-format file only for the new patches and newly
inserted lines. I am using VSCode IDE for development, and after some
modification, I can select the modified lines and apply formatting. It is
very useful for these cases. Otherwise, we need to handle so many things.
By the way, I am still working on macros. If you have any comments on this,
I would be very happy to discuss it.
> ...
