0

I was playing with ioctl and this question occurred to me.

Background

  1. I was told that the primary motivation for system calls is that the number of interrupt handlers allowed is very limited. So many OSes implement the abstraction of system calls (a.k.a. traps), which occupies only one interrupt number (0x80 in case of Linux), but accept extra arguments to deliver different functionalities on demand.
  2. this thread suggests the the number of system calls is actually very limited too, so the same reasoning above is applied again to invent ioctl.

Hence my question. Why don't OSes just offer enough system calls and get rid of ioctl? (Or is it just merely to create a hierarchical structure to offer better scalability?)

Community
  • 1
  • 1
wlnirvana
  • 1,811
  • 20
  • 36

1 Answers1

1

My opinion about this is that system calls can be viewed as a set of services provided by the operating system kernel to user applications, whereas ioctl is just one of these services that allows you to send a custom command to specific device (or driver).

When developing a driver, you may write a handler for incomming ioctl requests. Managing the same thing by implementing your own system calls has several disadvantages:

  • your implementation is specific to your driver, other components probably will not use it,
  • adding new system calls is not that easy – on WIndows, it is practically impossible because of Patchguard (Kernel Patch Protection),
  • on Windows, the kernel may help you with "validation" of I/O buffers for an IOCTL request, you must do all the work by yourself when implementing your own system calls.

You can view ioctl as a generalization for read and write. Both input and output buffers can be provided, together with a control code defining the action requred from the target (usually a kernel driver).

Martin Drab
  • 667
  • 4
  • 6
  • I think your answer makes more sense then the aforementioned post. Just to confirm, system calls are like a customizable handler for the OS to interact with CPU, while `ioctl` within the OS is a customizable handler for interaction between user space applications and the kernel? – wlnirvana Feb 16 '17 at 05:08
  • System call handlers are defined by the OS kernel as a communication mechanism between usermode and kernelmode (CPU may help by providing special instructions that make switching between user and kernel mode easier and cheaper) They are more or less hardcoded to the OS kernel (e.g. as a fixed array of routines implementing individual system calls). Requests generated on behalf of `ioctl` and several other system calls are usually sent to a driver responsible for the ioctl target, so the `ioctl` can be (into some extent) customized by the developer (in a documented manner). – Martin Drab Feb 16 '17 at 12:47