There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
Track the number of matches installed for a given multicast group, and leave the
group once no matches depend on it.
In order to handle passed-in sockets that are already members of multicast groups
we initialize the refcount based on the membership once we take over the socket.
This way we will leave the socket in the state we found it once we finish with
it.
On kernels that do not fully support reading out the multicast group membership
we fall back to never leaving any groups (as before).
By default we set as NLM_F_CREATE | NLM_F_EXCL in
sd_rtnl_message_new_link
But incase of bridge we need to set NLM_F_REQUEST | NLM_F_ACK.
If NLM_F_EXCL is set then we are unable to set the parameters. As bridge
supports setting properties after creation not during creation.
Though currently unused by us, netlink attribute types support embedding flags to indicate
if the type is encoded in network byte-order and if it is a nested attribute. Read out
these flags when parsing the message.
We will now swap the byteorder in case it is non-native when reading out integers (though
this is not needed by any of the types we currently support). We do not enforce the NESTED
flag, as the kernel gets this wrong in many cases.
Instead of representing containers as several arrays, make a new
netlink_container struct and keep one array of these structs. We
also introduce netlink_attribute structs that in the future will
hold meta-information about each atribute.
The kernel bonding layer allows passing an array of ARP IP targets as
bond-configuration. Due to the weird implementation of arrays in netlink
(which we haven't figure out a generic way to support, yet), we usually
hard-code the supported array-sizes. However, this should not be exported
from sd-netlink.
Instead, make sure the caller just uses it's current hack of enumerating
the types, and the sd-netlink core will have it's own list of supported
array-sizes (to be removed in future extensions, btw!). If either does not
match, we will just return a normal error.
Note that we provide 2 constants for ARP_IP_TARGETS_MAX now. However, both
have very different reasons:
- the constant in netdev-bond.c is used to warn the user that the given
number of targets might not be supported by the kernel (even though the
kernel might increase that number at _any_ time)
- the constant in sd-netlink is solely used due to us missing a proper
array implementation. Once that's supported in the type-system, it can
be removed without notice
Last but not least, this patch turns the log_error() into a log_warning().
Given that the previous condition was off-by-one, anyway, it never hit at
the right time. Thus, it was probably of no real use.
Explicitly export the root type-system to the type-system callers. This
avoids treating NULL as root, which for one really looks backwards (NULL
is usually a leaf, not root), and secondly prevents us from properly
debugging calling into non-nested types.
Also rename the root to "type_system_root". Once we support more than
rtnl, well will have to revisit that, anyway.
Empty type-systems are just fine. Avoid the nasty hack in
union-type-systems that treat empty type-systems as invalid. Instead check
for the actual types-array and make sure it's non-NULL (which is even true
for empty type-systems, due to "empty_types" array).
In sd-netlink-message, we always guarantee that the currently selected
type-system is non-NULL. Otherwise, we would be unable to parse any types
in the current container level. Hence, this assertion must be true:
message->container_type_system[m->n_containers] != NULL
During message_new() we currently do not verify that this assertion is
true. Instead, we blindly access nl_type->type_system and use it (which
might be NULL for basic types and unions). Fix this, by explicitly
checking that the root-level type is nested.
Note that this is *not* a strict requirement of netlink, but it's a strict
requirement for all message types we currently support. Furthermore, all
the callers of message_new() already verify that only supported types are
passed, therefore, this is a pure cosmetic check. However, it might be
needed on the future, so make sure we don't trap into this once we change
the type-system.
The NETLINK_TYPE_META pseudo-type is actually equivalent to an empty
nested type. Drop it and define an empty type-system instead.
This also has the nice side-effect that m->container_type_system[0] is
never NULL (which has really nasty side-effects if you try to read
attributes).
Right now we store the maximum type-ID of a type-system. This prevents us
from creating empty type-systems. Store the "count" instead, which should
be treated as max+1.
Note that type_system_union_protocol_get_type_system() currently has a
nasty hack to treat empty type-systems as invalid. This might need some
modification later on as well.
size_t is usually 64bit and int 32bit on a 64bit machine. This probably
does not matter for netlink message sizes, but nevertheless, avoid
hard-coding it anywhere.
Same as NLType, move NLTypeSystem into netlink-types.c and hide it from
the outside. Provide an accessor function for the 'max' field that is used
to allocate suitable array sizes.
Note that this will probably be removed later on, anyway. Once we support
bigger type-systems, it just seems impractical to allocate such big arrays
for each container entry. An RBTree would probably do just fine.
If we extend NLType to support arrays and further extended types, we
really want to avoid hard-coding the type-layout outside of
netlink-types.c. We already avoid accessing nl_type->type_system outside
of netlink-types.c, extend this to also avoid accessing any other fields.
Provide accessor functions for nl_type->type and nl_type->size and then
move NLType away from the type-system header.
With this in place, follow-up patches can safely turn "type_system" and
"type_system_union" into a real "union { }", and then add another type for
arrays.
Make sure we never access type->type_system or type->type_system_union
directly. This is an implementation detail of the type-system and we
should always use the accessors. Right now, they only exist for 2-level
accesses (type-system to type-system). This patch introduces the 1-level
accessors (type to type-system) and makes use of it.
This patch makes sure the proper assertions are in place, so we never
accidentally access sub-type-systems for non-nested/union types.
Note that this places hard-asserts on the accessors. This should be fine,
as we expect callers to only access sub type-systems if they *know*
they're dealing with nested types.
The NLA_ names are used to name real datatypes we extract out of netlink
messages. The kernel has an internal enum with the same names
(NLA_foobar), which is *NOT* binary compatible to our types. Furthermore,
we support a different set of types than the kernel (as we try to treat
some kernel peculiarities as our own types to simplify the API).
Rename NLA_ to NETLINK_TYPE_ to make clear that this is our own set of
types.
