Re: [libvirt] [PATCH v2 10/10] viriscsitest: Extend virISCSIConnectionLogin test

On 07/17/2018 09:15 PM, John Ferlan wrote: No. So { 0 } is basically a shortcut for: struct testIscsiadmCbData cbData; memset(&cbData, 0, sizeof(cbData)); It has nothing to do with the struct having only two bools (for now). It is used widely in our code, because it has one great advantage: even if we add/remove/rearrange items in the struct it is always going to be zeroed out whereas if I initialized it like this: struct testIscsiadmCbData cbData = {false, false}; and then somebody would append yet another member to the struct they would either: a) have to change all the lines where the struct is initialized (possibly touching functions that has nothing to do with actual change), or b) forget to initialize it completely. TL;DR It's just coincidence that the first member is a bool. Sure. That's how login works. Firstly it lists output of iscsi interfaces, then it creates a new one and then use that to log in. I don't see a problem here. Yes, this is "nada" ;-) I suggest opening virISCSIConnection() in another window and looking what it does (assuming that @initiatoriqn is set). So the first function that is called is virStorageBackendIQNFound() which execs `ISCSIADM --mode iface` to list all iscsi interfaces. If no libvirt interface is found IQN_MISSING is returned and virStorageBackendCreateIfaceIQN() is called. This function creates the interface and then calls virStorageBackendIQNFound() again to confirm the interface is created. Long story short, `ISCSIADM --mode iface` is called twice - before and after iface creation. Therefore we have to return different outputs to mimic the iface creation. What caller? Maybe you are confused what this callback is doing? The whole point of this callback is to avoid calling real iscsiadm binary AND having to write our own binary. We can write a function that is called instead of spawning real binary. But the function has to act like real binary - otherwise our code declares an erroneous binary. For instance: calling `iscsiadm --mode iface --op new --interface myInterface` creates new iscsi interface. Therefore, if I call `iscsiadm --mode iface` afterwards I have to see it in the list of the interfaces. And this is what the callback is doing. It doesn't have to take action for every combination of cmd line arguments in order to successfully mimic real iscsiadm binary behaviour. This fact is then noted as 'nada'. Because I want to test more than a single successful path in the code. If the interface doesn't exist initially, it is created and only then login is attempted. If it existed only login would be tested. Michal