• Michal Kubecek's avatar
    ethtool: netlink bitset handling · 10b518d4
    Michal Kubecek authored
    The ethtool netlink code uses common framework for passing arbitrary
    length bit sets to allow future extensions. A bitset can be a list (only
    one bitmap) or can consist of value and mask pair (used e.g. when client
    want to modify only some bits). A bitset can use one of two formats:
    verbose (bit by bit) or compact.
    
    Verbose format consists of bitset size (number of bits), list flag and
    an array of bit nests, telling which bits are part of the list or which
    bits are in the mask and which of them are to be set. In requests, bits
    can be identified by index (position) or by name. In replies, kernel
    provides both index and name. Verbose format is suitable for "one shot"
    applications like standard ethtool command as it avoids the need to
    either keep bit names (e.g. link modes) in sync with kernel or having to
    add an extra roundtrip for string set request (e.g. for private flags).
    
    Compact format uses one (list) or two (value/mask) arrays of 32-bit
    words to store the bitmap(s). It is more suitable for long running
    applications (ethtool in monitor mode or network management daemons)
    which can retrieve the names once and then pass only compact bitmaps to
    save space.
    
    Userspace requests can use either format; ETHTOOL_FLAG_COMPACT_BITSETS
    flag in request header tells kernel which format to use in reply.
    Notifications always use compact format.
    
    As some code uses arrays of unsigned long for internal representation and
    some arrays of u32 (or even a single u32), two sets of parse/compose
    helpers are introduced. To avoid code duplication, helpers for unsigned
    long arrays are implemented as wrappers around helpers for u32 arrays.
    There are two reasons for this choice: (1) u32 arrays are more frequent in
    ethtool code and (2) unsigned long array can be always interpreted as an
    u32 array on little endian 64-bit and all 32-bit architectures while we
    would need special handling for odd number of u32 words in the opposite
    direction.
    Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
    Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    10b518d4
bitset.c 19.7 KB