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' -- someone privileged enough needs to request
>> >> the change.
>> >> 
>> >> 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
>> > they are given the old name, which no longer exists.
>> Yes but why would anyone change interface name while dhclient-script is
>> running? Things will also go wrong if you try bringing interface down
>> during the run or do some other configuration, right? Running multiple
>> configuration tools at the same moment is a bad idea, you never know
>> what you're gonna end up with. 
>> As I see it, checks in kernel we have are meant to protect kernel
>> itself, not to disallow all user<->kernel interactions leading to
>> imperfect result.
>> (AFAIU) If we remove the check nothing is going to change: udev will
>> still be renaming interfaces before bringing them up. In netvsc case
>> users are not supposed to configure the VF interface at all, it just
>> becomes a slave of netvsc interface.
> Are we sending an event if device name is changed ?

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.

> If yes, your patch is fine.
> If not, daemons would not be aware the need to refresh their view of the
> world.

Yes but AFAIU daemons may need to do the same refresh when the interface
is down too (and, hopefully, they do it already).


Reply via email to