lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 05 Jun 2007 12:37:20 -0700 (PDT)
From:	David Miller <>
Subject: Re: [RFC RTNETLINK 00/09]: Netlink link creation API

From: Patrick McHardy <>
Date: Tue,  5 Jun 2007 16:12:51 +0200 (MEST)

> A few words about the API:
> Drivers wishing to use the API register a struct rtnl_link_ops, which
> contains a few function pointers for device setup, registation, changing
> and deletion, as well as netlink attribute validation and device dumping.
> All netlink communication happens within the AF_UNSPEC family. I
> initially introduced new netlink families for this, but removed them
> again since that would require adding new protocol families that serve
> no further purpose for most drivers. Additionally we currently use
> RTM.*LINK messages with ifi_family != AF_UNSPEC for information that
> is related to the device, but doesn't come from the driver that created
> the device itself, like bridge port state, IPv6 device configuration etc.
> The device specific attributes are nested within a new attribute
> IFLA_LINKINFO. I didn't use IFLA_PROTINFO since userspace can reasonably
> expect to have IFLA_PROTINFO unset for AF_UNSPEC messages, and the
> userspace STP daemon does that. Identification of the driver happens
> by name, stored in the IFLA_INFO_NAME attribute. IFLA_INFO_DATA contains
> driver specific attributes, IFLA_INFO_XSTATS driver specific statistics.
> The API does *not* use the existing RTM_SETLINK message type, instead
> it adds support for receiving RTM_NEWLINK within the kernel. I did this
> because of three reasons: 
> - RTM_SETLINK does not follow the usual rtnetlink conventions and ignores
>   all netlink flags
> - Other rtnetlink subsystems use the same message type for dumps and
>   notifications from the kernel as for configuration from userspace,
>   which usually allows to recreate an object by simply setting the
>   NLM_F_REQUEST flag on message received from the kernel and sending
>   it back.
> - Easier for userspace to detect support for the new features
> The RTM_NEWLINK message type is a superset of RTM_SETLINK, it allows
> to change both driver specific and generic attributes of the device.
> The set of generic device attributes that may be supplied during
> device creation is limited to a few simple ones, it currently does
> not support specifying link layer address/broadcast address as well
> as device flags. The change operation can change all device attributes.
> Not sure what else to say .. comments welcome.

This excellent description of the APIs (particularly the background
and reasoning) belongs in a file under Documentation/networking/ :-)
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists