On Tue, Jun 04, 2019 at 09:44:58AM +0200, Jan Tluka wrote:
Mon, Jun 03, 2019 at 07:08:54PM CEST, csfakian(a)redhat.com wrote:
>From: Christos Sfakianakis <csfakian(a)redhat.com>
>
>Hi,
>
>this patch allows the tester to check the remote type of of a device
>used in a test. In particular, it checks if a device is a generic
>device, a software device or a virtual device. A use case follows.
>
>==============================================================
>Controller
>==============================================================
>
>from lnst.Devices import VlanDevice
>from lnst.Devices.Device import Device as Dev
>from lnst.Devices.VlanDevice import VlanDevice as VlanDev
>from lnst.Devices.BridgeDevice import BridgeDevice as BridgeDev
>from lnst.Devices.SoftDevice import SoftDevice as SoftDev
>from lnst.Devices.VirtualDevice import VirtualDevice as VirtDev
>...
> host1.eth0 = DeviceReq(label="net1",
driver=RecipeParam("driver"))
> host1.vlan0 = VlanDevice(realdev=host1.eth0, vlan_id=10)
> x = host1.vlan0
>
> # Class hierarchy: Device >> SoftDevice >> VlanDevice
> # Device >> SoftDevice >> MasterDevice >>
BridgeDevice
> # Before | After
> -------------------
> isinstance(x, Dev) # True | True
> isinstance(x, SoftDev) # False | True
> isinstance(x, VlanDev) # False | True
> isinstance(x, BridgeDev) # False | False
>
> isinstance(host1.eth0, VirtDev) # True | True
> isinstance(x, VirtDev) # False | False
> |
>======================================================|=======
>Slave |
>======================================================|=======
> isinstance(dev, Dev) # True | True
> isinstance(dev, SoftDev) # True | True
> isinstance(dev, VlanDev) # True | True
> isinstance(dev, BridgeDev) # False | False
>
>
>The result on the slave hasn't changed. The result on the controller
>is now in agreement with that on the slave.
>
>Christos
>
Hi Christos, since you have written this nice explanation, I'd simply include
it in the patch itself.
Ondrej, what do you think? I'm asking for a generic advice if it's a
good practice to include the description of not-so-obvious use cases in
the patch itself. Personally, I think it should go in the patch.
-Jan
I agree, I think I've done something similar (though the use case was
much shorter) in the past. Examples:
commit 7d142416c7c44f967078b45c955ec5f4ec0cb668
commit 2b040d9601c62647ab79b15fd5987ae33f327172
-Ondrej