> I'm cautious about adding operational interfaces to sysfs because it > can be quite difficult to get the locking right. To begin with it > splits up a single interface into multiple files, any of which can > be held open by a process. Then there is the question of ordering > of operations when there are multiple users. For instance, if there > were two users, each of which using different transfer parameters, > a sysfs interface doesn't provide any mechanism to group setting up > the device with the transfer. > > These are lessons learned the hard way with the gpio sysfs abi. I > don't want to get caught in the same trap for spi. > > g.
I understand the problem, but I think that for very simple test on devices, sysfs is easier. For example, it happens that a SPI device does not work correctly with a driver, so I want to verify the SPI traffic by writing directly the device commands and check with an oscilloscope. I think that an easy way is to use sysfs like this: echo 123456 > speed_hz [other options if needed] echo -n -e "\x12\x34" > /dev/spidev1.1 [oscilloscope] hexdump -n 2 /dev/spidev1.1 This sysfs interface should be used only for testing/debugging, not to develop an user space driver on it; moreover, the ioctl interface is still there. spidev_test and spidev_fdx does not allow me to customize tx buffer and I think (very personal opinion) that for debugging purpose is better sysfs with well known programs (echo, cat, hexdump, od) and oscilloscope. I know that I'm not so persuasive :) I can develop a simple program that can write custom tx buf with ioctl -- Federico Vaga -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/