All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelianov <xemul@openvz.org>
To: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [PATCH 2/2] Virtual ethernet device driver
Date: Thu, 12 Jul 2007 17:14:34 +0400	[thread overview]
Message-ID: <4696293A.4030108@openvz.org> (raw)
In-Reply-To: <46961F21.7030409@trash.net>

Patrick McHardy wrote:
> Pavel Emelianov wrote:
>> +static int veth_newlink(struct net_device *dev,
>> +			 struct nlattr *tb[], struct nlattr *data[])
>> +{
>> +	int err;
>> +	struct net_device *peer;
>> +	struct veth_priv *priv;
>> +	char ifname[IFNAMSIZ];
>> +
>> +	/*
>> +	 * prepare the devices info
>> +	 */
>> +
>> +	if (tb[IFLA_ADDRESS] == NULL)
>> +		random_ether_addr(dev->dev_addr);
>> +
>> +	if (data != NULL && data[VETH_INFO_PEER] != NULL) {
>> +		err = nla_parse_nested(tb, IFLA_INFO_MAX,
>> +				data[VETH_INFO_PEER], ifla_policy);
>> +		if (err < 0)
>> +			return err;
>> +	}
> 
> 
> Not having a peer should be an error, no?

No. That's the intention - if the user doesn't specify "peer" in the
command line then two _identical_ devices are created. Of course, if
he specifies one name - there'll be a collision, but one can say
"my_own_veth_number_%d" and everything will be ok. Or just use the 
default name provided. E.g. "ip link add type veth" will send a packet
with data[VETH_INFO_PEER} == NULL, but this is OK! User just wants a 
default tunnel and he will get it :)

Does this answer your second comment below?

>> +
>> +	if (tb[IFLA_IFNAME])
>> +		nla_strlcpy(ifname, tb[IFLA_IFNAME], IFNAMSIZ);
>> +	else
>> +		snprintf(ifname, IFNAMSIZ, DRV_NAME "%%d");
> 
> 
> Does this work? The other device is not registered at this time, so I
> think the allocated names could clash ..
> 
> If it does work you could also perform name allocation in the
> rtnl_create_link function.
> 
> 
>> +
>> +	peer = rtnl_create_link(ifname, &veth_link_ops, tb);
>> +	if (IS_ERR(peer))
>> +		return PTR_ERR(peer);
>> +
>> +	if (tb[IFLA_ADDRESS] == NULL)
>> +		random_ether_addr(peer->dev_addr);
>> +
>> +	/*
>> +	 * register devices
>> +	 */
>> +
>> +	err = register_netdevice(peer);
>> +	if (err < 0)
>> +		goto err_register_peer;
>> +
>> +	err = register_netdevice(dev);
>> +	if (err < 0)
>> +		goto err_register_dev;
>> +
>> +	/*
>> +	 * tie the deviced together
>> +	 */
>> +
>> +	priv = netdev_priv(dev);
>> +	priv->dev = dev;
>> +	priv->peer = peer;
>> +	list_add(&priv->list, &veth_list);
>> +
>> +	priv = netdev_priv(peer);
>> +	priv->dev = peer;
>> +	priv->peer = dev;
>> +	INIT_LIST_HEAD(&priv->list);
>> +	return 0;
>> +
>> +err_register_dev:
>> +	unregister_netdevice(peer);
>> +	return err;
>> +
>> +err_register_peer:
>> +	free_netdev(peer);
>> +	return err;
>> +}
> 
>> +static __exit void veth_exit(void)
>> +{
>> +	struct veth_priv *priv, *next;
>> +
>> +	rtnl_lock();
>> +	__rtnl_link_unregister(&veth_link_ops);
>> +
>> +	list_for_each_entry_safe(priv, next, &veth_list, list)
>> +		veth_dellink(priv->dev);
>> +	rtnl_unlock();
> 
> 
> Devices are unregistered automatically through the dellink function,
> rtnl_link_unregister(..) is enough.

OK. This looks like a minor and not-significant comment, so
do I need to resend the patch or David is OK to take it and
I will send an incremental one?

Thanks,
Pavel

  reply	other threads:[~2007-07-12 13:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-12  9:13 [PATCH 0/2] Virtual ethernet device (v3) Pavel Emelianov
2007-07-12  9:17 ` [PATCH 1/2] Introduce the generic rtnl_create_link() Pavel Emelianov
2007-07-12  9:19 ` [PATCH 2/2] Virtual ethernet device driver Pavel Emelianov
2007-07-12 12:31   ` Patrick McHardy
2007-07-12 13:14     ` Pavel Emelianov [this message]
2007-07-12 13:21       ` Patrick McHardy
2007-07-12 13:36         ` Pavel Emelianov
2007-07-12 13:44           ` Patrick McHardy
2007-07-12 13:58             ` Pavel Emelianov
2007-07-12 13:17     ` Pavel Emelianov
2007-07-12 13:24       ` Patrick McHardy
2007-07-16  9:10         ` Pavel Emelianov
2007-07-12 13:51   ` Patrick McHardy
2007-07-12 14:01     ` Pavel Emelianov
2007-07-12 14:10       ` Patrick McHardy
2007-07-16  9:16         ` Pavel Emelianov
2007-07-16 13:13           ` Patrick McHardy
2007-07-12  9:21 ` [PATCH 0/2] Module for ip utility to support veth device (v.3) Pavel Emelianov
2007-07-12  9:23   ` [PATCH 1/2] Intruduce iplink_parse() routine Pavel Emelianov
2007-07-12  9:25   ` [PATCH 2/2] Module for ip utility to support veth device Pavel Emelianov
  -- strict thread matches above, loose matches on Subject: below --
2007-07-19  9:24 [PATCH] Virtual ethernet device (v.4) Pavel Emelyanov
2007-07-19  9:28 ` [PATCH 2/2] Virtual ethernet device driver Pavel Emelyanov

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=4696293A.4030108@openvz.org \
    --to=xemul@openvz.org \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.