utils: add code comment about capability number assignment

Also reserve a range of capabilities (0x7000 to 0x7FFF) that we won't
use upstream. Add a macro NL_CAPABILITY_IS_USER_RESERVED() to check
if the capability is in that range.

Signed-off-by: Thomas Haller <thaller@redhat.com>
This commit is contained in:
Thomas Haller 2015-03-19 12:22:12 +01:00
parent ff19c781d3
commit 860ea27a46
2 changed files with 23 additions and 2 deletions

View file

@ -129,8 +129,15 @@ enum {
NL_CAPABILITY_ROUTE_ADDR_COMPARE_CACHEINFO = 6,
#define NL_CAPABILITY_ROUTE_ADDR_COMPARE_CACHEINFO NL_CAPABILITY_ROUTE_ADDR_COMPARE_CACHEINFO
__NL_CAPABILITY_MAX
#define NL_CAPABILITY_MAX (__NL_CAPABILITY_MAX - 1)
__NL_CAPABILITY_MAX,
NL_CAPABILITY_MAX = (__NL_CAPABILITY_MAX - 1),
#define NL_CAPABILITY_MAX NL_CAPABILITY_MAX
/**
* The range 0x7000 to 0x7FFF is reserved for private capabilities. Upstream libnl3 will
* not register capabilities in this range. However, instead of adding private capabilities,
* better register their number with upstream libnl3. */
#define NL_CAPABILITY_IS_USER_RESERVED(cap) ( ((cap) & ~0x0FFF) == 0x7000 )
};
int nl_has_capability (int capability);

View file

@ -1152,6 +1152,20 @@ int nl_has_capability (int capability)
NL_CAPABILITY_ROUTE_ADDR_COMPARE_CACHEINFO,
0,
0),
/* IMPORTANT: these capability numbers are intended to be universal and stable
* for libnl3. Don't allocate new numbers on your own that differ from upstream
* libnl3.
*
* Instead register a capability number upstream too. We will take patches
* for that. We especially take patches to register a capability number that is
* only implemented in your fork of libnl3.
*
* If you really don't want that, use capabilities in the range 0x7000 to 0x7FFF.
* (NL_CAPABILITY_IS_USER_RESERVED). Upstream libnl3 will not register conflicting
* capabilities in that range.
*
* Obviously, only backport capability numbers to libnl versions that actually
* implement that capability as well. */
#undef _NL_SET
#undef _NL_SETV
#undef _NL_ASSERT