netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: netdev@vger.kernel.org
Cc: socketcan@hartkopp.net, hadi@cyberus.ca, xemul@sw.ru,
	Patrick McHardy <kaber@trash.net>,
	ebiederm@xmission.com, tgraf@suug.ch
Subject: [RFC RTNETLINK 00/09]: Netlink link creation API
Date: Tue,  5 Jun 2007 16:12:51 +0200 (MEST)	[thread overview]
Message-ID: <20070605141250.15650.47178.sendpatchset@localhost.localdomain> (raw)

The following patches contain the rtnetlink link creation API I promised,
as well as two simple driver conversion to use the API as an example.
I've also converted VLAN as a more complex example, but these patches
need some more work and are most likely not interesting to all the CCed
parties, so I'm sending them seperately.

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.


 drivers/net/dummy.c               |  144 +++++++-----
 drivers/net/ifb.c                 |  115 ++++++---
 include/linux/if_link.h           |   13 +
 include/linux/netdevice.h         |    3 
 include/net/fib_rules.h           |    2 
 include/net/genetlink.h           |    2 
 include/net/ip_fib.h              |    2 
 include/net/netlink.h             |   12 -
 include/net/rtnetlink.h           |   57 ++++
 net/core/neighbour.c              |    4 
 net/core/rtnetlink.c              |  451 +++++++++++++++++++++++++++++++++-----
 net/decnet/dn_dev.c               |    2 
 net/decnet/dn_rules.c             |    2 
 net/ipv4/devinet.c                |    2 
 net/ipv4/fib_frontend.c           |    2 
 net/ipv4/fib_rules.c              |    2 
 net/ipv6/addrconf.c               |    2 
 net/ipv6/fib6_rules.c             |    2 
 net/ipv6/route.c                  |    2 
 net/netlabel/netlabel_cipso_v4.c  |    2 
 net/netlabel/netlabel_mgmt.c      |    2 
 net/netlabel/netlabel_unlabeled.c |    2 
 net/netlink/attr.c                |    8 
 net/netlink/genetlink.c           |    2 
 24 files changed, 665 insertions(+), 172 deletions(-)

Patrick McHardy (9):
      [NETLINK]: Mark netlink policies const
      [RTNETLINK]: ifindex 0 does not exist
      [RTNETLINK]: Split up rtnl_setlink
      [RTNETLINK]: Link creation API
      [DUMMY]: Use dev->stats
      [DUMMY]: Keep dummy devices on list
      [DUMMY]: Use rtnl_link API
      [IFB]: Keep ifb devices on list
      [IFB]: Use rtnl_link API

             reply	other threads:[~2007-06-05 14:12 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-05 14:12 Patrick McHardy [this message]
2007-06-05 14:12 ` [RFC NETLINK 01/09]: Mark netlink policies const Patrick McHardy
2007-06-05 19:39   ` David Miller
2007-06-05 14:12 ` [RFC RTNETLINK 02/09]: ifindex 0 does not exist Patrick McHardy
2007-06-05 19:40   ` David Miller
2007-06-05 14:12 ` [RFC RTNETLINK 03/09]: Split up rtnl_setlink Patrick McHardy
2007-06-05 19:41   ` David Miller
2007-06-05 14:12 ` [RFC RTNETLINK 04/09]: Link creation API Patrick McHardy
2007-06-05 19:43   ` David Miller
2007-06-05 21:09     ` Patrick McHardy
2007-06-05 22:03   ` Stephen Hemminger
2007-06-05 23:17     ` Patrick McHardy
2007-06-05 23:16       ` Stephen Hemminger
2007-06-06 11:42         ` Patrick McHardy
2007-06-06 16:37   ` Eric W. Biederman
2007-06-06 16:50     ` Patrick McHardy
2007-06-06 18:02       ` Eric W. Biederman
2007-06-05 14:12 ` [RFC DUMMY 05/09]: Use dev->stats Patrick McHardy
2007-06-05 19:44   ` David Miller
2007-06-05 14:13 ` [RFC DUMMY 06/09]: Keep dummy devices on list Patrick McHardy
2007-06-05 19:44   ` David Miller
2007-06-05 14:13 ` [RFC DUMMY 07/09]: Use rtnl_link API Patrick McHardy
2007-06-05 19:46   ` David Miller
2007-06-05 14:13 ` [RFC IFB 08/09]: Keep ifb devices on list Patrick McHardy
2007-06-05 14:13 ` [RFC IFB 09/09]: Use rtnl_link API Patrick McHardy
2007-06-05 14:18 ` [RFC IPROUTE]: iplink: use netlink for link configuration Patrick McHardy
2007-06-05 19:37 ` [RFC RTNETLINK 00/09]: Netlink link creation API David Miller
2007-06-05 21:10   ` Patrick McHardy
2007-06-05 22:00 ` jamal
2007-06-05 22:07   ` Patrick McHardy
2007-06-05 22:29     ` jamal
2007-06-06  0:40 ` Eric W. Biederman
2007-06-06 11:50   ` Patrick McHardy
2007-06-06 15:25     ` Eric W. Biederman
2007-06-06 15:35       ` Patrick McHardy
2007-06-06 15:56         ` Alexey Kuznetsov
2007-06-06 16:32           ` Patrick McHardy
2007-06-06 17:31             ` Eric W. Biederman
2007-06-06 19:14             ` Alexey Kuznetsov
2007-06-07  8:06               ` Eric W. Biederman
2007-06-06 16:13         ` Eric W. Biederman
2007-06-06 16:25           ` Patrick McHardy
2007-06-06 13:46 ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070605141250.15650.47178.sendpatchset@localhost.localdomain \
    --to=kaber@trash.net \
    --cc=ebiederm@xmission.com \
    --cc=hadi@cyberus.ca \
    --cc=netdev@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    --cc=tgraf@suug.ch \
    --cc=xemul@sw.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).