fix: libnl codex bug
BREAKING CHANGE: extends key in config file is now used for extending other config files
style：modify libnl driver style
docs：NA
test：NA
Signed-off-by: YOUR_NAME <xusai4@huawei.com>
- existing API/ABI must stay unchanged. We cannot change parameter
types. Ad most we can add new variants that support 64 bit integers.
- rtnl_tc_calc_txtime64() and rtnl_tc_calc_bufsize64() are trivial.
We should not blow up the public API of libnl for such a thing.
If the users needs it, they can just reimplement it.
- getters should return an error code. Especially if the return type
does not support encoding an error there.
- don't add separate rs_rate64/rs_ceil64 field. Instead, extend the
"rs_rate" field of "struct rtnl_ratespec" to 64 bits. It's internal
API.
Rebased original pull request #214 on master. One commit ("xfrmi: add
IFLA_XFRM_* definitions to if_link.h") was thereby dropped as it
is no longer necessary. Otherwise, the two remaining patches applied
cleanly. Then, add two more patches to the branch before merging.
https://github.com/thom311/libnl/pull/214
Returning the value directly as uint32_t does not leave room for an error
code. E.g. we want to indicate to the caller whether the attribute is present
or not (-NLE_NOATTR). Currenlty, the code is quite unforgiving and will just
crash/assert against invalid arguments. In theory, we could also be more forgiving
and return a error code if the link argument is invalid.
Just be more forgiving. Also, this avoids a coverity warning:
Error: FORWARD_NULL (CWE-476): [#def1]
libnl-3.4.0/lib/route/addr.c:502: var_compare_op: Comparing "a->a_peer" to null implies that "a->a_peer" might be null.
libnl-3.4.0/lib/route/addr.c:513: var_deref_model: Passing null pointer "a->a_peer" to "nl_addr_cmp", which dereferences it.
libnl-3.4.0/lib/addr.c:587:8: deref_parm: Directly dereferencing parameter "a".
# 585| int nl_addr_cmp(const struct nl_addr *a, const struct nl_addr *b)
# 586| {
# 587|-> int d = a->a_family - b->a_family;
# 588|
# 589| if (d == 0) {
https://bugzilla.redhat.com/show_bug.cgi?id=1606988
This fixes the build with musl libc.
Additionally, several changes were made to account for changes to the
headers:
- ip_mp_alg.h was removed, since it was removed in linux commit e06e7c61
(v2.6.23), and the last use of those constants was removed in libnl
commit 535e8316.
- Uses of TCF_META_ID_SK_ROUTE_CAPS were updated to
__TCF_META_ID_SK_ROUTE_CAPS, since it was renamed in linux commit
e20e6940 (v3.1).
- Uses of IF_CARRIER_DOWN and IF_CARRIER_UP were replaced with their
values, 0 and 1, since they are not in linux/if.h (they appear to be
libnl-specific, added in libnl commit 3540e44b).
https://github.com/thom311/libnl/pull/222
These behave the same, except when used at top-level. This can't happen
since the macro body is a statement.
__func__ is standardized since C99, while __PRETTY_FUNCTION__ is a
GNU extension.
