Purely technically - not much. the ioctl method will automatically grab the Big Kernel Lock for you, which you probably don't want and the system call won't do - but you can avoid that by implementing the ioctl_unlocked method instead of normal ioctl.
More broadly speaking, the list of system calls needs to be globally coordinated and therefore entry into the list is guarded pretty closely. A device specific call wouldn't make the cut - and eventually some other code would be given the syscall number you are using, and you would have ABI problems.
That being said, ioctl() is discouraged too because of its type and opaqueness issues. Tho I've got to say that personally I think most of the alternatives (sysfs, read/write of blobs, even proc) can be pretty opaque too.
ioctl vs system call
Purely technically - not much. the ioctl method will automatically grab the Big Kernel Lock for you, which you probably don't want and the system call won't do - but you can avoid that by implementing the ioctl_unlocked method instead of normal ioctl.
More broadly speaking, the list of system calls needs to be globally coordinated and therefore entry into the list is guarded pretty closely. A device specific call wouldn't make the cut - and eventually some other code would be given the syscall number you are using, and you would have ABI problems.
That being said, ioctl() is discouraged too because of its type and opaqueness issues. Tho I've got to say that personally I think most of the alternatives (sysfs, read/write of blobs, even proc) can be pretty opaque too.
--
Linux Consulting
http://www.ducksong.com/
http://bitsup.blogspot.com/