sysfs "trailing newline" behaviour can't be easily mocked

[hadess]

If I were to write a sysfs attribute, in most cases, cating it back should result in the same data I wrote, plus a newline being printed. Unfortunately, there doesn't seem to be a way to mock that behaviour in umockdev.

See https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/347 for a bug I couldn't test in the test suite.

$ echo "accel_3d-dev0" >  /sys/devices/platform/AMDI0010:02/i2c-2/i2c-BMA250E:00/0018:6243:0001.0002/HID-SENSOR-200073.2.auto/iio:device0/trigger/current_trigger
$ cat /sys/devices/platform/AMDI0010:02/i2c-2/i2c-BMA250E:00/0018:6243:0001.0002/HID-SENSOR-200073.2.auto/iio:device0/trigger/current_trigger
accel_3d-dev0
$

[Benjamin Berg]

Heh, I was actually thinking of abusing that in the libfprint test suite to see whether libfprint wrote the file. But, I guess I could also look a the ctime.

[Martin Pitt]

At first sight that sounds like issue #115 which was fixed more than two years ago in commit 1b58d24. But that was about umockdev-record, and it seems you try this directly with "echo", outside of any umockdev stuff.

$ echo "accel_3d-dev0" > ...

Supposedly you wanted to do echo -n here and not actually append a newline to the file? And you expect this to still implicitly get a newline when you read it back?

This "reading automatically implies a newline" seems driver specific, especially for binary attributes:

❱❱❱ od -x /sys/devices/pci0000:00/0000:00:1d.4/0000:05:00.0/0000:06:02.0/0000:2d:00.0/usb6/descriptors
0000000 0112 0310 0009 0903 1d6b 0003 0517 0203
0000020 0101 0209 001f 0101 e000 0900 0004 0100
0000040 0009 0000 0507 0381 0004 060c 0030 0200
0000060 0000
0000061

❱❱❱ od -x /sys/devices/pci0000:00/0000:00:1d.4/0000:05:00.0/0000:06:02.0/0000:2d:00.0/usb6/quirks
0000000 7830 0a30
0000004

But this is inconsistent also for textual attributes:

❱❱❱ od -x /sys/devices/pci0000:00/0000:00:1d.4/0000:05:00.0/0000:06:02.0/0000:2d:00.0/usb6/idProduct
0000000 3030 3330 000a
0000005

❱❱❱ od -x /sys/devices/pci0000:00/0000:00:1d.4/0000:05:00.0/0000:06:02.0/0000:2d:00.0/usb6/manufacturer
0000000 694c 756e 2078 2e35 3731 302e 332d 3030
0000020 662e 3363 2e36 3878 5f36 3436 7820 6368
0000040 2d69 6368 0a64

❱❱❱ od -x /sys/devices/pci0000:00/0000:00:1d.4/0000:05:00.0/0000:06:02.0/0000:2d:00.0/usb6/removable
0000000 6e75 6e6b 776f 0a6e
0000010

I.e. the removable attribute contains unknown, manufacturer contains Linux 5.17.0-300.fc36.x86_64 xhci-hcd, while idProduct contains 0003\n (newline).

(this is my actual system, not mocked). So this seems so arbitrary and coincidental that I'm afraid libumockdev just can't emulate that.

Or did I misunderstand you? If so, what precisely did you expect to happen with your commands?

[hadess]

Supposedly you wanted to do echo -n here and not actually append a newline to the file? And you expect this to still implicitly get a newline when you read it back?

Right. The kernel doesn't make a difference here.

This "reading automatically implies a newline" seems driver specific, especially for binary attributes:

I don't expect binary attributes to be adding data, obviously, but text, and single value ones almost always do though:

$ git grep sysfs_emit | grep '\\n' | wc -l
1670

Obviously umockdev doesn't know which attributes behave this way, but we do because we have the sources for it. It would be useful to be able to do that for specific attributes, to mock the kernel more closely and catch more potential mistakes.