One-Way System Calls
Although partially resolved in Linux by the NetLink API, it's very difficult to get data out of the kernel. There's no standard mechanism for a UNIX kernel to call a function in a UNIX program. In fact, it's very difficult to send more than one bit of information to a user space program from the kernel. The one bit is a signal, a flag saying that something has happened. Consider the example of an asynchronous I/O request. Ideally, you would like some notification when your I/O operation has completed. On UNIX, you receive a signal. This tells you that an asynchronous I/O operation has happened, but not which one—you then have to poll all of them to try to find out.
The lack of this mechanism dramatically increases the number of things that must be done in the kernel. It's a UNIX axiom that policy and mechanism must be separated, and yet it's very difficult to provide mechanism in a UNIX kernel and policy outside, since the kernel has no way of informing a user space delegate that some kind of policy decision is required. The standard UNIX workaround to this problem is to have a program initiate a system call that then blocks until the kernel has something to say and returns at some later time.
Note that this doesn't apply to microkernel UNIX-like systems, such as GNU HURD or Mach. These systems use a very simple kernel that provides a simple interface to the hardware and message-passing facilities, and run everything else in user space. Since the kernel in these systems delegates a lot to user space servers, it needs a mechanism for sending messages, and this mechanism is available to all user space programs.