Stephen Hemminger writes:
> On Thu, 10 Aug 2017 10:55:01 -0600
> David Ahern wrote:
>
>> On 8/10/17 10:48 AM, David Miller wrote:
>> > From: Andrew Lunn
>> > Date: Thu, 10 Aug 2017 18:27:22 +0200
>> >
>> >> On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
>> >>> Andrew Lun
On Thu, 10 Aug 2017 10:55:01 -0600
David Ahern wrote:
> On 8/10/17 10:48 AM, David Miller wrote:
> > From: Andrew Lunn
> > Date: Thu, 10 Aug 2017 18:27:22 +0200
> >
> >> On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
> >>> Andrew Lunn writes:
> >>>
> > We are - rtn
On 8/10/17 10:48 AM, David Miller wrote:
> From: Andrew Lunn
> Date: Thu, 10 Aug 2017 18:27:22 +0200
>
>> On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
>>> Andrew Lunn writes:
>>>
> We are - rtnetlink_event() does the job. We, however, don't have a
> special IFLA_EVEN
From: Andrew Lunn
Date: Thu, 10 Aug 2017 18:27:22 +0200
> On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
>> Andrew Lunn writes:
>>
>> >> We are - rtnetlink_event() does the job. We, however, don't have a
>> >> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NO
Andrew Lunn writes:
> On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
>> Andrew Lunn writes:
>>
>> >> We are - rtnetlink_event() does the job. We, however, don't have a
>> >> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
>> >
>> > What is in this event?
On Thu, Aug 10, 2017 at 05:24:55PM +0200, Vitaly Kuznetsov wrote:
> Andrew Lunn writes:
>
> >> We are - rtnetlink_event() does the job. We, however, don't have a
> >> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
> >
> > What is in this event? Old and new name? Just the ne
Andrew Lunn writes:
>> We are - rtnetlink_event() does the job. We, however, don't have a
>> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
>
> What is in this event? Old and new name? Just the new name?
Basically, it's everything we know about the interface - type, index,
> We are - rtnetlink_event() does the job. We, however, don't have a
> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
What is in this event? Old and new name? Just the new name?
Andrew
> >> Can you think of any particular real world scenarios which are broken by
> >> the change?
> >
> > How about:
> >
> > man 8 dhclient-script
> >
> > The interface name is passed in $interface to the scripts. Do we get
> > the old name or the new name? I suspect scripts are going to break if
> >
Eric Dumazet writes:
> On Thu, 2017-08-10 at 10:41 +0200, Vitaly Kuznetsov wrote:
>> Andrew Lunn writes:
>>
>> >> I understand the 'legacy' concern but at the same time we don't want to
>> >> have aftificial limitations too. Name change, in particular, doesn't
>> >> happen 'under the hood' -- s
On Thu, 2017-08-10 at 10:41 +0200, Vitaly Kuznetsov wrote:
> Andrew Lunn writes:
>
> >> I understand the 'legacy' concern but at the same time we don't want to
> >> have aftificial limitations too. Name change, in particular, doesn't
> >> happen 'under the hood' -- someone privileged enough needs
Andrew Lunn writes:
>> I understand the 'legacy' concern but at the same time we don't want to
>> have aftificial limitations too. Name change, in particular, doesn't
>> happen 'under the hood' -- someone privileged enough needs to request
>> the change.
>>
>> Can you think of any particular rea
> I understand the 'legacy' concern but at the same time we don't want to
> have aftificial limitations too. Name change, in particular, doesn't
> happen 'under the hood' -- someone privileged enough needs to request
> the change.
>
> Can you think of any particular real world scenarios which are
吉藤英明 writes:
> 2017-08-09 19:42 GMT+09:00 Vitaly Kuznetsov :
>> What happens is: __netvsc_vf_setup() does dev_open() for the VF device and
>> the consecutive dev_change_name() fails with -EBUSY because of the
>> (dev->flags & IFF_UP) check. The history of this code predates git so I
>> wasn't abl
2017-08-09 19:42 GMT+09:00 Vitaly Kuznetsov :
> What happens is: __netvsc_vf_setup() does dev_open() for the VF device and
> the consecutive dev_change_name() fails with -EBUSY because of the
> (dev->flags & IFF_UP) check. The history of this code predates git so I
> wasn't able to figure out when
Recent 'transparenf VF' changes to netvsc driver made VF interfaces
register as netvsc interface slaves upon appearance. This led to udev
not being able to rename the interface according to the 'predictable
interface names' scheme:
kernel: mlx4_core 0002:00:02.0 eth2: joined to eth1
kernel: hv_n
16 matches
Mail list logo
