6. Adventures in ioctl(2) Support

• See ioctl_list(2)

6.1 Decoding Request Numbers

• first impression: large but limited set
• switch: they don't play well together
  one ioctl handler per source file
• reality: private request numbers
• ambiguity: private and historical (look at file descriptor)
• internal table of pointers (not a problem yet); slide
• ...each has optional "method" to disambiguate
• URL.. follow along the source code

6.2 Representation

• "fildes" is handled the same way as the other system calls
• "request" is handled on previous slide
• accurate representation of 3rd argument; slide
• ...each ioctl request has "method" to print data
• ...output-only requests just print the pointer

6.3 Explanations

• each ioctl request has "method" to print explanation; slide
• set set of errno(3) value usually not documented
• this is where you read kernel source

6.4 EINVAL vs ENOTTY

• like system calls, this is messy; slide
• kernel source comments indicate this may be being dealt with
• also: ENOSYS, ENOTSUP EOPNOTSUP, and (not Linux) ENOIOCTL

6.5 intptr_t

• shoe-horn
• prototype; slide
• ...bye bye type safety
• tcflush(3) and friends
• [e]glibc internally: two ways
• sys_ioctl
• cognitive dissonance = bugs
• intptr_t