Support returning error codes from attribute reads

[gicmo]

I would like to simulate the "safe mode" for thunderbolt devices in the self test of fwupd's thunderbolt plugin. For this a read of the sysfs attribute nvm_version needs to return ENODATA on read. I could not see how that is currently doable. If it isn't, it would be a cool feature to add.

[martinpitt]

This is indeed not currently possible. I'm trying to think of a sane way how to represent this on a plain file system; you could create the attributes as Unix sockets or pipes for more control, but neither of them can be coerced to return ENODATA on read. ENODATA isn't even a defined error code on read(2).

Do you need this right at the first read() or after some bytes of actual data? Is that really a read() or maybe some higher-level function in libudev? However, the only two cases in libudev/libsd-device that return ENODATA are udev_device_get_subsystem() (if there is no subsystem) or sd_device_get_usec_since_initialized() (if there is no USEC_INITIALIZED value). Neither seem to be the case here, or are they?

[martinpitt]

@gicmo : ping?

[gicmo]

Sorry for the delay:
That would indeed be directly from read (or for other tests, write). In the thunderbolt test cases also for bolt, I am writing actual data to /sys/bus/thunderbolt/devices/X/key and .../authorized and the kernel (not udev) can (and will for invalid data) reject the write with something like EKEYREJECTED. So I thought it would be great if we could have a function with a path and an error code (umockdev_testbed_simualte_ioerror (const char *path, int error)) and subsequet read/write calls would fail with said error code, so we could test the code handles error returned from the kernel correctly.

[dlech]

Could we use something like ptrace to intercept and modify syscalls? Once upon a time, I used PRoot that does something like this.

[dlech]

Or perhaps one could use libfuse?