Johannes Berg wrote: > On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote: > > >>Same way as the current RTM_SETLINK message works, but with creating >>a new link in advance. It works fine in other subsystems, so I don't >>see why it would in this case as well. Some subsystems do it in an >>atomic fashion (network schedulers for example), some first create >>the object, then configure it (network classifiers in the non-compat >>cases). In the network device case I suppose the later should work >>fine since a device needs to be set UP in a second action before >>it really does anything. > > > Looking at br_netlink.c it seems that this sort of contradicts why > generic netlink was done, now all the sudden everything that wants to > create new links need its own netlink protocol number, no? No, generic netlink avoids allocating netlink families. br_netlink uses the same netlink family as the other network configuration stuff (NETLINK_ROUTE), but a different rtgen_family (which matches the address families). But you have a valid point, if we want to use this for things like bonding or VLAN that aren't actually address families, we should consider introducing "rtnetlink families" to avoid adding AF_BONDING, AF_8021Q etc. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
