This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [RFC PATCH 32/33] Add the Xen virtual network device dri

To: Arjan van de Ven <arjan@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC PATCH 32/33] Add the Xen virtual network device driver.
From: jamal <hadi@xxxxxxxxxx>
Date: Tue, 18 Jul 2006 08:39:39 -0400
Cc: Andrew Morton <akpm@xxxxxxxx>, Zachary Amsden <zach@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Andi Kleen <ak@xxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Thu, 20 Jul 2006 05:18:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1153218477.3038.46.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: unknown
References: <20060718091807.467468000@xxxxxxxxxxxx> <20060718091958.414414000@xxxxxxxxxxxx> <1153218477.3038.46.camel@xxxxxxxxxxxxxxxxxxxxx>
Reply-to: hadi@xxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2006-18-07 at 12:27 +0200, Arjan van de Ven wrote:

> Hmmm maybe it's me, but something bugs me if a NIC driver is going to
> send IP level ARP packets... that just feels very very wrong and is a
> blatant layering violation.... 

It is but the bonding driver has been setting precedence for years now
on sending ARPs from a driver;->
It does make a lot of sense to put it in user space. More interesting
policies may include sending more than just ARPs and once you hard-code
in the kernel you loose that flexibility.

> shouldn't the ifup/ifconfig scripts just
> be fixed instead if this is critical behavior?

I dont think the ifup/ifconfig provide operational status (i.e link
up/down) - or do they? If they can be made to invoke scripts in such
a case then we are set.

Note: you will get netlink events when devices are created or devices
change their admin (via ifconfig) or operational (link down/up) status.
[Try running "ip monitor" to see]

One could write a little daemon that reacts to these specific events.
The problem has been some people claiming that daemons are a bad idea
from a usability perspective. Patrick has mentioned he may be working on
a daemon in user space that does exactly that. The other alternative is
to do the udev thing and have the kernel invoke a script whenever an
event of interest happens.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>