[libvirt] [PATCH] Remove MAX_TAP_ID, take 3

[Matthias Bolte]

2009/7/30 Mark McLoughlin <markmc at redhat.com>:
> On Thu, 2009-07-30 at 02:58 +0200, Matthias Bolte wrote:
>> 2009/7/29 Daniel Veillard <veillard at redhat.com>:
>> > On Wed, Jul 29, 2009 at 08:05:37PM +0200, Daniel Veillard wrote:
>> >> On Wed, Jul 29, 2009 at 12:52:30PM -0400, Aron Griffis wrote:
>> >> > This is a resend of take 2 to fix formatting problems in the
>> >> > patch.  No other changes.
>> >> >
>> >> > 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.
>> >>
>> >>   haha ! that one worked :-)
>> >>
>> >> I will review and apply, thanks !
>> >
>> >  Actually just looking at brAddTap() after patching makes it clear,
>> > and based on Mark and Dan feedback great !
>> >  Applied and commited to git, thanks !
>> >
>> > Daniel
>>
>> This patch breaks -Werror, because GCC is unhappy with the initializer
>> for ifreq.
>>
>> The follow change makes GCC happy again:
>>
>> diff --git a/src/bridge.c b/src/bridge.c
>> index ec37192..6480a35 100644
>> --- a/src/bridge.c
>> +++ b/src/bridge.c
>> @@ -465,7 +465,7 @@ brAddTap(brControl *ctl,
>>           int *tapfd)
>>  {
>>      int fd, len;
>> -    struct ifreq ifr = {0};
>> +    struct ifreq ifr = {{{0}}, {{0, {0}}}};
>
> AFAIR, this works?
>
>  struct ifreq ifr = {0,};
>
> Cheers,
> Mark.
>

No, it doesn't, I tested it. The problem is the internal structure of
ifreq. GCC complains until the initializer matches this structure. Or
use memset like all other bridge functions do:

struct ifreq ifr;
memset(&ifr, 0, sizeof(struct ifreq));

Matthias