>I suggest you think about what an ioctl is >and why we're going through a process of trying to get rid of them in >the kernel: They're structured streams of information, where the >structure is architecture and 64/32 bit dependent (look at all the >issues over compat ioctls). I think that's a poor characterization of an ioctl. _Some_ ioctls have an architecture and 64/32 bit dependent structure, but it isn't inherent in an ioctl. In fact, most ioctls don't have that problem. What an ioctl is is something that's defined for a special case (e.g. a certain device type). The lesson from the compat ioctl mess is that it hurts to have special cases. Plenty of system calls are as architecture-dependent as any ioctl, but since they aren't defined separately in every device driver, they're easier to update for new architectures. Incidentally, I'm reserving judgment on whether the disadvantages of ioctls outweigh their advantages. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
