On Sun, 20 May 2001, Edgar Toernig wrote: > IMHO any similar powerful (and versatile) interface will see the same > problems. Enforcing a read/write like interface (and rejecting drivers > that pass ptrs through this interface) may give you some knowledge about > the kernel/userspace communication. But the data the flows around will > become the same mess that is present with the current ioctl. Every driver > invents its own sets of commands, its own rules of argument parsing, ... > Maybe it's no longer strange binary data but readable ASCII strings but > that's all. Look at how many different "styles" of /proc files there are. Too many people who don't know C and manage to get their crap into the tree. Shame, but that is _not_ a technical problem. > IMHO what's needed is a definition for "sane" in this context. Trying > to limit the kind of actions performed by ioctls is not "sane". Then > people will always revert back to old ioctl. "Sane" could be: network > transparent, architecture independant, usable with generic tools and non > C-like languages. /me points to UNIX-like OS that had done that. BTW, network-transparent means "no pointers"... - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
