[PATCH 3/3] C/R: Basic support for network namespaces and devices (v2)

David Miller davem at davemloft.net
Sat Jan 23 01:25:37 PST 2010


From: Dan Smith <danms at us.ibm.com>
Date: Fri, 22 Jan 2010 13:09:52 -0800

> +	if (strcmp(dev->name, "sit0") == 0) {
> +		return 0;                                    /* Skip sit0 */
> +	} else if (dev->ethtool_ops && dev->ethtool_ops->get_drvinfo) {
> +		dev->ethtool_ops->get_drvinfo(dev, &drvinfo);
> +		if (strcmp(drvinfo.driver, "veth") == 0)
> +			return 1;                            /* vethX is okay */
> +	} else if (strcmp(dev->name, "lo") == 0)
> +		return 1;                                    /* lo is okay */
 ...
> +	if (strcmp(dev->name, "lo") == 0)
> +		h->type = CKPT_NETDEV_LO;
> +	else if (strncmp(dev->name, "veth", 4) == 0) {
> +		h->type = CKPT_NETDEV_VETH;
> +		peer = veth_get_peer(dev);
> +	} else {

This is gross.  You can't do things this way.

First of all, devices can get whatever name the user wants
to assign to them.  If they want to rename the loopback
device to something other than "lo" they can.

You need another way.  Is it such a stretch of ingenuity to
simply add an attribute flag to struct netdev that you can test
here and perhaps a callback for what you need?

Your direct calls into these drivers, like the veth bits, will not
work if the driver is built modular.  It's one of several reasons
why doing things this way isn't going to work.

This misdesign is also why you find a need to get at the RTNL link ops
too.  You have no infrastructure for doing what you need to do
generically, so instead you are forced to directly call into drivers
and export RTNL internals needlessly.

This needs a lot of work, sorry.


More information about the Containers mailing list