On Wed, 2009-07-29 at 17:32 +0100, Daniel P. Berrange wrote:
On Wed, Jul 29, 2009 at 12:27:58AM -0400, Aron Griffis wrote:
> (Sorry, my first posting included some gnulib droppings in the
> patch. This removes that, everything else is the same.)
>
> As far as I can tell, there's no reason to format the device string in
> brAddTap(). Delegate the job to TUNSETIFF, thereby removing the loop
> and the MAX_TAP_ID artificial limit. This patch allows me to get
> 421 guests running before hitting other limits.
Very bizarre, the kernel seems to interpret 'vnet%d' and auto
fillin the unique integer for us. So this patch is just removing
the equivalent logic from libvirt. Wonder why we had it there in
the first place !
I could think of two theories:
1) I had a vague notion older kernel versions rejected any names
containing %d except tun%d or tap%d; not true, this behaviour looks
like it has been around forever
2) Maybe we were doing it so as to avoid querying the ifname the
kernel allocated; that would be silly, since SETIFF does return the
allocated name to userspace
So, I dunno either - maybe it was just a misunderstanding about (1)
Patch looks good to me
Cheers,
Mark.