From: Patrick McHardy <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
