Jeff Garzik wrote: > I'll probably have to illustrate with code, but basically, read/write > can be completely ignorant of 32/64-bit architecture, endianness, it can > even be network-transparent. ioctls just can't do that. Apart from the network transparency, yes they can. Ioctl is no different from read/write/read-modify-write except the additional command argument. You can write architecture-specific ioctls which take and return structs -- and you can do the same with read/write. This is what Andi is thinking of as dangerous: the read/write case is then much harder to emulate. Or, you can write architecture-independent read/write, which use fixed formats, which you seem to have in mind. That works fine with ioctls too. It isn't commonly done, because people prefer the convenience of a struct. But it does work. It's slightly easier in the driver to implement commands this way using an ioctl, because you don't have to check the read/write length. It's about the same to use from userspace: both read/write and ioctl methods using an architecture-independent data format require the program to lay out the command bytes and then issue one system call. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
