Re: [Xen-devel] [PATCH 4/4] [Net] Support accelerated network plugin modules

2007-06-15 Thread Keir Fraser
On 15/6/07 17:22, "Kieran Mansley" <[EMAIL PROTECTED]> wrote: > The lock protects the use_count variable. Yes, that's one thing I noticed -- can you use atomic_t for reference counts and hence reduce the number of times you need to lock/unlock? At least the open-coded lock-decrement-test-maybe-fr

Re: [Xen-devel] [PATCH 0/4] [Net] Support accelerated network plugin modules

2007-06-15 Thread Keir Fraser
On 15/6/07 13:21, "Michael Buesch" <[EMAIL PROTECTED]> wrote: >> True in general, but not the cases I've seen in this patchset, where 'foo' >> is a predicate. > > Ok, if foo is a variable containing an error code, it's > better to return that error code. I assumed that foo is a > variable cont

Re: [Xen-devel] [PATCH 0/4] [Net] Support accelerated network plugin modules

2007-06-15 Thread Keir Fraser
On 15/6/07 13:11, "Michael Buesch" <[EMAIL PROTECTED]> wrote: >> No use of the following please: >> If (foo) return 1; else return 0; >> Is clearer as: >> Return foo; > > But it's not the same. > return !!foo; > would be the same. And yes, it does matter: True in general, but not the cases I'

Re: [Xen-devel] [PATCH 0/4] [Net] Support accelerated network plugin modules

2007-06-15 Thread Keir Fraser
On 15/6/07 11:46, "Kieran Mansley" <[EMAIL PROTECTED]> wrote: > This is a repost of some earlier patches to the xen-devel mailing list, > with a number of changes thanks to some useful suggestions from others. The coding style needs fixing in various ways. Hard tabs need to be used, no spaces in

Re: [Xen-devel] Re: [PATCH 3/4] [Net] Support Xen accelerated network plugin modules

2007-05-22 Thread Keir Fraser
On 22/5/07 13:44, "Kieran Mansley" <[EMAIL PROTECTED]> wrote: >> Eagerly zap the function pointers, then wait one RCU period so every CPU >> goes through a quiescent point before unloading the module? >> >> -- Keir > > Am I right in thinking that if one of the functions that was protected > by

Re: [Xen-devel] Re: [PATCH 3/4] [Net] Support Xen accelerated network plugin modules

2007-05-22 Thread Keir Fraser
On 22/5/07 08:28, "Kieran Mansley" <[EMAIL PROTECTED]> wrote: > On Tue, 2007-05-22 at 08:15 +0100, Kieran Mansley wrote: >> RCU on its own wouldn't >> prevent the accelerated plugin being unloaded while netfront was using >> one of the hooks. > > Hmm, actually I think it could be used to do th

Re: [RFC] Arp announce (for Xen)

2007-03-02 Thread Keir Fraser
On 2/3/07 01:30, "Stephen Hemminger" <[EMAIL PROTECTED]> wrote: > What about implementing the unused arp_announce flag on the inetdevice? > Something like the following. Totally untested... > > Looks like it either was there (and got removed) or was planned but > never implemented. This would b

Re: [RFC PATCH 32/33] Add the Xen virtual network device driver.

2006-07-18 Thread Keir Fraser
On 18 Jul 2006, at 11:27, 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 shouldn't the ifup/ifconfig scripts just be fixed instead if this is criti

Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.

2006-05-11 Thread Keir Fraser
On 11 May 2006, at 01:33, Herbert Xu wrote: But if sampling virtual events for randomness is really unsafe (is it really?) then native guests in Xen would also get bad random numbers and this would need to be somehow addressed. Good point. I wonder what VMWare does in this situation. Well,

Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.

2006-05-10 Thread Keir Fraser
On 10 May 2006, at 00:51, Chris Wright wrote: * Herbert Xu ([EMAIL PROTECTED]) wrote: Chris Wright <[EMAIL PROTECTED]> wrote: + netdev->features= NETIF_F_IP_CSUM; Any reason why IP_CSUM was chosen instead of HW_CSUM? Doing the latter would seem to be in fact easier for a virt

Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.

2006-05-09 Thread Keir Fraser
On 9 May 2006, at 21:25, Stephen Hemminger wrote: + memcpy(netdev->dev_addr, info->mac, ETH_ALEN); + network_connect(netdev); + info->irq = bind_evtchn_to_irqhandler( + info->evtchn, netif_int, SA_SAMPLE_RANDOM, netdev->name, This doesn't look like a real rand