Re: [Xen-devel] [PATCH 3.4] xen-netback: allow changing the MAC address of the interface

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 06/06/14 21:02, Daniel Kiper wrote:
> On Fri, Jun 06, 2014 at 06:56:23AM -0700, Greg KH wrote:
>> On Fri, Jun 06, 2014 at 03:04:17PM +0200, Daniel Kiper wrote:
>>> On Thu, Jun 05, 2014 at 04:14:58PM -0700, Greg KH wrote:
>>>> On Thu, Jun 05, 2014 at 02:58:44PM -0700, David Miller wrote:
>>>>> From: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
>>>>> Date: Mon,  2 Jun 2014 21:46:20 +0200
>>>>>
>>>>>> From: Matt Wilson <msw@xxxxxxxxxx>
>>>>>>
>>>>>> Sometimes it is useful to be able to change the MAC address of the
>>>>>> interface for netback devices. For example, when using ebtables it may
>>>>>> be useful to be able to distinguish traffic from different interfaces
>>>>>> without depending on the interface name.
>>>>>>
>>>>>> Reported-by: Nikita Borzykh <sample.n@xxxxxxxxx>
>>>>>> Reported-by: Paul Harvey <stockingpaul@xxxxxxxxxxx>
>>>>>> Cc: netdev@xxxxxxxxxxxxxxx
>>>>>> Cc: xen-devel@xxxxxxxxxxxxx
>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>>>>>> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>>>>>> Signed-off-by: Matt Wilson <msw@xxxxxxxxxx>
>>>>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>>>>>> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
>>>>>> (cherry picked from commit 4a633a602c26497b8285a202830829d3be007c7b)
>>>>>>
>>>>>> Signed-off-by: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
>>>>>> Tested-by: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
>>>>>> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>>>>> I don't think this is suitable for -stable.
>>>>>
>>>>> -stable should be restricted bug fixes for things that either
>>>>> are extremely serious, or hit a very huge segment of the user
>>>>> base.
>>>>>
>>>>> This issue does not quality for either condition.
>>>> Yeah, it seems like a new feature to me, I'll drop it from my to-apply
>>>> queue.
>>> Yes, in fact it is, however, without it toolstack pollute 
>>> /var/log/xen/xen-hotplug.log
>>> with "RTNETLINK answers: Operation not supported" error when every domain 
>>> is started.
>>> Additionally, it is simple two liner and it should not break anything 
>>> (Konrad and
>>> I did some tests and everything looks OK). I do not mention that from time 
>>> to time
>>> we add some features like support for new hardware with just new device ID 
>>> (e.g.
>>> USB devices). So that is why I decided to post this patch to stable.
>> New device ids and quirks to existing drivers are valid stable patches
>> (see Documentation/stable_kernel_rules.txt), but new features usually
>> are not.
> There is something like that:
>  - It must fix a problem that causes a build error (but not for things
>    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>    security issue, or some "oh, that's not good" issue.  In short,
>    something critical.
>
> I think that this is "oh, that's not good" issue type. Of course it
> is not so critical but a bit annoying. Hence, could we have it in 3.4
> or "NO" is your the last word in that case?
>
> Daniel

The phrase "oh, that's not good" is usually said with a very distinctive
tone of voice, and has an habit of attracting a crowd of developers when
uttered in an office setting.

Its implied meaning is quite far from its literal meaning.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel