Adding device fills some attributes after sending the uevent

[benzea]

There is a problem affecting hotplug in libusb. It reads the device descriptors immediately after it receives the uevent. However, the descriptor is a binary attribute.

I was setting it by using umockdev_testbed_add_from_string, but the uevent is already send by umockdev_testbed_add_devicev.

My thinking to fix this is to add umockdev_testbed_add_devicev2, etc. which do not emit the uevent. Then the API user needs to do so manually, fixing the issue. This allows firing the uevent from umockdev_testbed_add_from_string, fixing the issue mostly (though even there we could add umockdev_testbed_add_from_string2 to move the responsibility to the API user.

Not sure what to do, but, as it is now, one needs to have all USB devices configured before initializing libusb. Otherwise setup will always race with the hotplug monitoring thread that libusb is running.

[martinpitt]

May I ask, what's the use case here? I find it rather correct that umockdev_testbed_add_devicev() immediately sends the uevent. If you add/change a second event, it will send another uevent, yes -- but that's exactly what happens on a real system as well. These two devices are independent, after all.

If a test relies on creating a device without an uevent, it makes unrealistic assumptions IMHO -- either set up the mock env before you launch the test subject, or fix it to expect uevents for both devices.

[martinpitt]

Oh wait, I think I completely misunderstood your description. This is entirely inside add_dev_from_string() which either needs to add the binary and link attributes before, or indeed use an internal add_devicev() which does not send the uevent. But that won't touch the external API at all.

[martinpitt]

@benzea: Fixed in PR #174