On Thu, 26 Aug 2021 at 15:59, Denis Kenzior <denkenz(a)gmail.com> wrote:
>> Use of struct in_addr would imply network order is being
used. Same as
>> inet_ntoa/inet_ntop, etc.
> Right, and same as __be32. __be32 has the advantage that it's not a
> struct so, 1. you know its size and contents and can pass its pointer
> directly to, say, an attribute builder without looking up internal
> structures, 2. don't need to convert to/from it by assigning cryptic
> field names, 3. can pass it as parameter.
Some of what you say isn't really correct. Look at the signature of inet_ntoa
You're arguing for use of __be32 because you store ipv4 addresses as uints. I
get that. But that doesn't help you with ipv6 and there is already a well
defined structure to represent an ipv4 address.
I'd argue that an array for ipv6 is still more practical than the same
array wrapped in a struct (basically same thing as with IPv4 in_addr)
Anyhow, given how you're planning to use this, I'd just adopt a signature
similar to inet_ntop. Something like:
l_rtnl_neighbor_set_hwaddr(rtnl, ifindex, int family, const void *, const
uint8_t *hwaddr, size_t hwaddr_len, cb, user_data, destroy)
Also, US spelling of 'neighbor' would be preferred.
The reason I chose neighbour is because that is the name of the kernel
API but ok.