Well. I given an example of device which doesn't fit into read()/write() interface.
Your imagination is truely appreciated - and you are encouraged to try to implement it. With full error handling (every write must be checked)
and multithreading support (e.g. one user for movement, multiple for monitoring and diagnosis).In that case I'd use two device nodes. One for the command/error stuff, and another for
I have tryed to some extent impelementing something like this - amount of code doubled for no real gain. (It was in those times when "ioctl()s are bad. period." topic poped up on lkml first time. long time ago)
I haven't suggested any xml, perhaps someone else did. A write interface let you pass
No one will ever design interface for sake of interface. what you are proposing - probably will look nice in academical papers, but no one will do it, and no one will do it in kernel space.
And all this stuff - all this funcy xml-like comlications? - for what? just call one function of driver with single parameter - void*.
_*Not more*_. Ridiculous indeed.
P.S. As I have said before, it seems to me that using read()/write() instead of ioctl() could be the only choice. I once hacked read(): user must pass two structures: first is input, second is output. It worked - but no one (including me) liked it. ioctl() even by its name fit better.