In Chapter 3, we built a complete device driver that the user can write to and read from. But a real device usually offers more functionality than synchronous read and write. Now that we’re equipped with debugging tools should something go awry, we can safely go ahead and implement new operations.
What is normally needed, in addition to reading and writing the device, is the ability to perform various types of hardware control via the device driver. Control operations are usually supported via the ioctl method. The alternative is to look at the data flow being written to the device and use special sequences as control commands. This latter technique should be avoided because it requires reserving some characters for controlling purposes; thus, the data flow can’t contain those characters. Moreover, this technique turns out to be more complex to handle than ioctl. Nonetheless, sometimes it’s a useful approach to device control and is used by tty’s and other devices. We’ll describe it later in this chapter in Section 5.1.7.
As we suggested in the previous chapter, the ioctl system call offers a device specific entry point for the driver to handle “commands.” ioctl is device specific in that, unlike read and other methods, it allows applications to access features unique to the hardware being driven, such as configuring the device and entering or exiting operating modes. These control operations are usually not available through the read/write file abstraction. For example, everything you write to a serial port is used as communication data, and you cannot change the baud rate by writing to the device. That is what ioctl is for: controlling the I/O channel.
Another important feature of real devices (unlike scull) is that data being read or written is exchanged with other hardware, and some synchronization is needed. The concepts of blocking I/O and asynchronous notification fill the gap and are introduced in this chapter by means of a modified scull device. The driver uses interaction between different processes to create asynchronous events. As with the original scull, you don’t need special hardware to test the driver’s workings. We will definitely deal with real hardware, but not until Chapter 8.
The ioctl function call in user space corresponds to the following prototype:
int ioctl(int fd, int cmd, ...);
The prototype stands out in the list of Unix system calls because of
the dots, which usually represent not a variable number of arguments.
In a real system, however, a system call can’t actually have a
variable number of arguments. System calls must have a well-defined
number of arguments because user programs can access them only through
hardware “gates,” as outlined in Section 2.1.1 in
Chapter 2. Therefore, the dots in the prototype
represent not a variable number of arguments but a single optional
argument, traditionally identified as char *argp.
The dots are simply there to prevent type checking during
compilation. The actual nature of the third argument depends on the
specific control command being issued (the second argument). Some
commands take no arguments, some take an integer value, and some take
a pointer to other data. Using a pointer is the way to pass arbitrary
data to the ioctl call; the device will then be
able to exchange any amount of data with user space.
The ioctl driver method, on the other hand, receives its arguments according to this declaration:
int (*ioctl) (struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
The inode and filp pointers are
the values corresponding to the file descriptor fd
passed on by the application and are the same parameters passed to the
open method. The cmd argument
is passed from the user unchanged, and the optional
arg argument is passed in the form of an
unsigned long, regardless of whether it was given
by the user as an integer or a pointer. If the invoking program
doesn’t pass a third argument, the arg value
received by the driver operation has no meaningful value.
Because type checking is disabled on the extra argument, the compiler can’t warn you if an invalid argument is passed to ioctl, and the programmer won’t notice the error until runtime. This lack of checking can be seen as a minor problem with the ioctl definition, but it is a necessary price for the general functionality that ioctl provides.
As you might imagine, most ioctl implementations
consist of a switch statement that selects the
correct behavior according to the cmd
argument. Different commands have different numeric values, which are
usually given symbolic names to simplify coding. The symbolic name is
assigned by a preprocessor definition. Custom drivers usually declare
such symbols in their header files; scull.h
declares them for scull. User programs
must, of course, include that header file as well to have access to
those symbols.
Before writing the code for ioctl, you need to choose the numbers that correspond to commands. Unfortunately, the simple choice of using small numbers starting from 1 and going up doesn’t work well.
The command numbers should be unique across the system in order to
prevent errors caused by issuing the right command to the wrong
device. Such a mismatch is not unlikely to happen, and a program might
find itself trying to change the baud rate of a non-serial-port input
stream, such as a FIFO or an audio device. If each
ioctl number is unique, then the application will
get an EINVAL error rather than succeeding in doing
something unintended.
To help programmers create unique ioctl command codes, these codes have been split up into several bitfields. The first versions of Linux used 16-bit numbers: the top eight were the “magic” number associated with the device, and the bottom eight were a sequential number, unique within the device. This happened because Linus was “clueless” (his own word); a better division of bitfields was conceived only later. Unfortunately, quite a few drivers still use the old convention. They have to: changing the command codes would break no end of binary programs. In our sources, however, we will use the new command code convention exclusively.
To choose ioctl numbers for your driver according
to the new convention, you should first check
include/asm/ioctl.h and
Documentation/ioctl-number.txt. The header
defines the bitfields you will be using: type (magic number), ordinal
number, direction of transfer, and size of argument. The
ioctl-number.txt file lists the magic numbers
used throughout the kernel, so you’ll be able to choose your own magic
number and avoid overlaps. The text file also lists the reasons why
the convention should be used.
The old, and now deprecated, way of choosing an
ioctl number was easy: authors chose a magic
eight-bit number, such as “k” (hex 0x6b), and
added an ordinal number, like this:
#define SCULL_IOCTL1 0x6b01 #define SCULL_IOCTL2 0x6b02 /* .... */
If both the application and the driver agreed on the numbers, you only
needed to implement the switch statement in your
driver. However, this way of defining ioctl
numbers, which had its foundations in Unix tradition, shouldn’t be
used any more. We’ve only shown the old way to give you a taste of
what ioctl numbers look like.
The new way to define numbers uses four bitfields, which have
the following meanings. Any new symbols we introduce in the following list
are defined in <linux/ioctl.h>.
-
type The magic number. Just choose one number (after consulting
ioctl-number.txt) and use it throughout the driver. This field is eight bits wide (_IOC_TYPEBITS).-
number The ordinal (sequential) number. It’s eight bits (
_IOC_NRBITS) wide.-
direction The direction of data transfer, if the particular command involves a data transfer. The possible values are
_IOC_NONE(no data transfer),_IOC_READ,_IOC_WRITE, and_IOC_READ | _IOC_WRITE(data is transferred both ways). Data transfer is seen from the application’s point of view;_IOC_READmeans reading from the device, so the driver must write to user space. Note that the field is a bit mask, so_IOC_READand_IOC_WRITEcan be extracted using a logical AND operation.-
size The size of user data involved. The width of this field is architecture dependent and currently ranges from 8 to 14 bits. You can find its value for your specific architecture in the macro
_IOC_SIZEBITS. If you intend your driver to be portable, however, you can only count on a size up to 255. It’s not mandatory that you use thesizefield. If you need larger data structures, you can just ignore it. We’ll see soon how this field is used.
The header file <asm/ioctl.h>, which is included by <linux/ioctl.h>, defines macros
that help set up the command numbers as follows: _IO(type,nr),
_IOR(type,nr,dataitem),
_IOW(type,nr,dataitem), and
_IOWR(type,nr,dataitem). Each macro corresponds to
one of the possible values for the direction of the transfer. The
type and number fields are
passed as arguments, and the size field is derived
by applying sizeof to the
dataitem argument. The header also defines macros
to decode the numbers: _IOC_DIR(nr),
_IOC_TYPE(nr), _IOC_NR(nr), and
_IOC_SIZE(nr). We won’t go into any more detail
about these macros because the header file is clear, and sample code
is shown later in this section.
Here is how some ioctl commands are defined in scull. In particular, these commands set and get the driver’s configurable parameters.
/* Use 'k' as magic number */ #define SCULL_IOC_MAGIC 'k' #define SCULL_IOCRESET _IO(SCULL_IOC_MAGIC, 0) /* * S means "Set" through a ptr * T means "Tell" directly with the argument value * G means "Get": reply by setting through a pointer * Q means "Query": response is on the return value * X means "eXchange": G and S atomically * H means "sHift": T and Q atomically */ #define SCULL_IOCSQUANTUM _IOW(SCULL_IOC_MAGIC, 1, scull_quantum) #define SCULL_IOCSQSET _IOW(SCULL_IOC_MAGIC, 2, scull_qset) #define SCULL_IOCTQUANTUM _IO(SCULL_IOC_MAGIC, 3) #define SCULL_IOCTQSET _IO(SCULL_IOC_MAGIC, 4) #define SCULL_IOCGQUANTUM _IOR(SCULL_IOC_MAGIC, 5, scull_quantum) #define SCULL_IOCGQSET _IOR(SCULL_IOC_MAGIC, 6, scull_qset) #define SCULL_IOCQQUANTUM _IO(SCULL_IOC_MAGIC, 7) #define SCULL_IOCQQSET _IO(SCULL_IOC_MAGIC, 8) #define SCULL_IOCXQUANTUM _IOWR(SCULL_IOC_MAGIC, 9, scull_quantum) #define SCULL_IOCXQSET _IOWR(SCULL_IOC_MAGIC,10, scull_qset) #define SCULL_IOCHQUANTUM _IO(SCULL_IOC_MAGIC, 11) #define SCULL_IOCHQSET _IO(SCULL_IOC_MAGIC, 12) #define SCULL_IOCHARDRESET _IO(SCULL_IOC_MAGIC, 15) /* debugging tool */ #define SCULL_IOC_MAXNR 15
The last command, HARDRESET, is used to reset the
module’s usage count to 0 so that the module can be unloaded should
something go wrong with the counter. The actual source file also
defines all the commands between IOCHQSET and
HARDRESET, although they’re not shown here.
We chose to implement both ways of passing integer arguments—by
pointer and by explicit value, although by an established convention
ioctl should exchange values by pointer.
Similarly, both ways are used to return an integer number: by pointer
or by setting the return value. This works as long as the return value
is a positive integer; on return from any system call, a positive
value is preserved (as we saw for read and
write), while a negative value is considered an
error and is used to set errno in user space.
The “exchange” and “shift” operations are not particularly useful for scull. We implemented “exchange” to show how the driver can combine separate operations into a single atomic one, and “shift” to pair “tell” and “query.” There are times when atomic[24] test-and-set operations like these are needed, in particular, when applications need to set or release locks.
The explicit ordinal number of the command has no specific meaning. It is used only to tell the commands apart. Actually, you could even use the same ordinal number for a read command and a write command, since the actual ioctl number is different in the “direction” bits, but there is no reason why you would want to do so. We chose not to use the ordinal number of the command anywhere but in the declaration, so we didn’t assign a symbolic value to it. That’s why explicit numbers appear in the definition given previously. The example shows one way to use the command numbers, but you are free to do it differently.
The value of the ioctl
cmd
argument is not currently used by the kernel, and it’s quite unlikely
it will be in the future. Therefore, you could, if you were feeling
lazy, avoid the complex declarations shown earlier and explicitly
declare a set of scalar numbers. On the other hand, if you did, you
wouldn’t benefit from using the bitfields. The header
<linux/kd.h> is an example of this
old-fashioned approach, using 16-bit scalar values to define the
ioctl commands. That source file relied on
scalar numbers because it used the technology then available, not out
of laziness. Changing it now would be a gratuitous incompatibility.
The implementation of ioctl is usually a
switch statement based on the command number. But
what should the default selection be when the
command number doesn’t match a valid operation? The question is
controversial. Several kernel functions return
-EINVAL (“Invalid argument”), which makes sense
because the command argument is indeed not a valid one. The POSIX
standard, however, states that if an inappropriate
ioctl command has been issued, then
-ENOTTY should be returned. The string associated
with that value used to be “Not a typewriter” under all libraries up
to and including libc5. Only
libc6 changed the message to
“Inappropriate ioctl for device,” which looks more to the
point. Because most recent Linux system are
libc6 based, we’ll stick to the standard
and return -ENOTTY. It’s still pretty common,
though, to return -EINVAL in response to an invalid
ioctl command.
Though the ioctl system call is most often used to act on devices, a few commands are recognized by the kernel. Note that these commands, when applied to your device, are decoded before your own file operations are called. Thus, if you choose the same number for one of your ioctl commands, you won’t ever see any request for that command, and the application will get something unexpected because of the conflict between the ioctl numbers.
The predefined commands are divided into three groups:
Those that can be issued on any file (regular, device, FIFO, or socket)
Those that are issued only on regular files
Those specific to the filesystem type
Commands in the last group are executed by the implementation of the hosting filesystem (see the chattr command). Device driver writers are interested only in the first group of commands, whose magic number is “T.” Looking at the workings of the other groups is left to the reader as an exercise; ext2_ioctl is a most interesting function (though easier than you may expect), because it implements the append-only flag and the immutable flag.
The following ioctl commands are predefined for any file:
-
FIOCLEX Set the close-on-exec flag (File IOctl CLose on EXec). Setting this flag will cause the file descriptor to be closed when the calling process executes a new program.
-
FIONCLEX -
FIOASYNC Set or reset asynchronous notification for the file (as discussed in Section 5.4 later in this chapter). Note that kernel versions up to Linux 2.2.4 incorrectly used this command to modify the
O_SYNCflag. Since both actions can be accomplished in other ways, nobody actually uses theFIOASYNCcommand, which is reported here only for completeness.-
FIONBIO “File IOctl Non-Blocking I/O” (described later in this chapter in Section 5.2.4). This call modifies the
O_NONBLOCKflag infilp->f_flags. The third argument to the system call is used to indicate whether the flag is to be set or cleared. We’ll look at the role of the flag later in this chapter. Note that the flag can also be changed by the fcntl system call, using the F_SETFL command.
The last item in the list introduced a new system call,
fcntl, which looks like
ioctl. In fact, the fcntl
call is very similar to ioctl in that it gets a
command argument and an extra (optional) argument. It is kept separate
from ioctl mainly for historical reasons: when
Unix developers faced the problem of controlling I/O operations, they
decided that files and devices were different. At the time, the only
devices with ioctl implementations were ttys,
which explains why -ENOTTY is the standard reply
for an incorrect ioctl command. Things have
changed, but fcntl remains in the name of
backward compatibility.
Another point we need to cover before looking at the ioctl code for the scull driver is how to use the extra argument. If it is an integer, it’s easy: it can be used directly. If it is a pointer, however, some care must be taken.
When a pointer is used to refer to user space, we must ensure that the user address is valid and that the corresponding page is currently mapped. If kernel code tries to access an out-of-range address, the processor issues an exception. Exceptions in kernel code are turned to oops messages by every Linux kernel up through 2.0.x; version 2.1 and later handle the problem more gracefully. In any case, it’s the driver’s responsibility to make proper checks on every user-space address it uses and to return an error if it is invalid.
Address verification for kernels 2.2.x and beyond
is implemented by the function access_ok, which
is declared in <asm/uaccess.h>:
int access_ok(int type, const void *addr, unsigned long size);
The first argument should be either VERIFY_READ or
VERIFY_WRITE, depending on whether the action to be
performed is reading the user-space memory area or writing it. The
addr argument holds a user-space address, and
size is a byte count. If
ioctl, for instance, needs to read an integer
value from user space, size is
sizeof(int). If you need to both read and write at
the given address, use VERIFY_WRITE, since it is a
superset of VERIFY_READ.
Unlike most functions, access_ok returns a boolean
value: 1 for success (access is OK) and 0 for failure (access is not
OK). If it returns false, the driver will usually return
-EFAULT to the caller.
There are a couple of interesting things to note about access_ok. First is that it does not do the complete job of verifying memory access; it only checks to see that the memory reference is in a region of memory that the process might reasonably have access to. In particular, access_ok ensures that the address does not point to kernel-space memory. Second, most driver code need not actually call access_ok. The memory-access routines described later take care of that for you. We will nonetheless demonstrate its use so that you can see how it is done, and for backward compatibility reasons that we will get into toward the end of the chapter.
The scull source exploits the bitfields in
the ioctl number to check the arguments before
the switch:
int err = 0, tmp; int ret = 0; /* * extract the type and number bitfields, and don't decode * wrong cmds: return ENOTTY (inappropriate ioctl) before access_ok() */ if (_IOC_TYPE(cmd) != SCULL_IOC_MAGIC) return -ENOTTY; if (_IOC_NR(cmd) > SCULL_IOC_MAXNR) return -ENOTTY; /* * the direction is a bitmask, and VERIFY_WRITE catches R/W * transfers. `Type' is user oriented, while * access_ok is kernel oriented, so the concept of "read" and * "write" is reversed */ if (_IOC_DIR(cmd) & _IOC_READ) err = !access_ok(VERIFY_WRITE, (void *)arg, _IOC_SIZE(cmd)); else if (_IOC_DIR(cmd) & _IOC_WRITE) err = !access_ok(VERIFY_READ, (void *)arg, _IOC_SIZE(cmd)); if (err) return -EFAULT;
After calling access_ok, the driver can safely
perform the actual transfer. In addition to the
copy_from_user and
copy_to_user functions, the programmer can
exploit a set of functions that are optimized for the most-used data
sizes (one, two, and four bytes, as well as eight bytes on 64-bit
platforms). These functions are described in the following list and
are defined in <asm/uaccess.h>.
-
put_user(datum, ptr),__put_user(datum, ptr) These macros write the datum to user space; they are relatively fast, and should be called instead of copy_to_user whenever single values are being transferred. Since type checking is not performed on macro expansion, you can pass any type of pointer to put_user, as long as it is a user-space address. The size of the data transfer depends on the type of the
ptrargument and is determined at compile time using a special gcc pseudo-function that isn’t worth showing here. As a result, ifptris a char pointer, one byte is transferred, and so on for two, four, and possibly eight bytes.put_user checks to ensure that the process is able to write to the given memory address. It returns 0 on success, and
-EFAULTon error. __put_user performs less checking (it does not call access_ok), but can still fail on some kinds of bad addresses. Thus, __put_user should only be used if the memory region has already been verified with access_ok.As a general rule, you’ll call __put_user to save a few cycles when you are implementing a read method, or when you copy several items and thus call access_ok just once before the first data transfer.
-
get_user(local, ptr),__get_user(local, ptr) These macros are used to retrieve a single datum from user space. They behave like put_user and __put_user, but transfer data in the opposite direction. The value retrieved is stored in the local variable
local; the return value indicates whether the operation succeeded or not. Again, __get_user should only be used if the address has already been verified with access_ok.
If an attempt is made to use one of the listed functions to transfer a value that does not fit one of the specific sizes, the result is usually a strange message from the compiler, such as “conversion to non-scalar type requested.” In such cases, copy_to_user or copy_from_user must be used.
Access to a device is controlled by the permissions on the device file(s), and the driver is not normally involved in permissions checking. There are situations, however, where any user is granted read/write permission on the device, but some other operations should be denied. For example, not all users of a tape drive should be able to set its default block size, and the ability to work with a disk device does not mean that the user can reformat the drive. In cases like these, the driver must perform additional checks to be sure that the user is capable of performing the requested operation.
Unix systems have traditionally restricted privileged operations to the superuser account. Privilege is an all-or-nothing thing—the superuser can do absolutely anything, but all other users are highly restricted. The Linux kernel as of version 2.2 provides a more flexible system called capabilities. A capability-based system leaves the all-or-nothing mode behind and breaks down privileged operations into separate subgroups. In this way, a particular user (or program) can be empowered to perform a specific privileged operation without giving away the ability to perform other, unrelated operations. Capabilities are still little used in user space, but kernel code uses them almost exclusively.
The full set of capabilities can be found in
<linux/capability.h>. A subset of those
capabilities that might be of interest to device driver writers
includes the following:
-
CAP_DAC_OVERRIDE The ability to override access restrictions on files and directories.
-
CAP_NET_ADMIN The ability to perform network administration tasks, including those which affect network interfaces.
-
CAP_SYS_MODULE -
CAP_SYS_RAWIO The ability to perform “raw” I/O operations. Examples include accessing device ports or communicating directly with USB devices.
-
CAP_SYS_ADMIN A catch-all capability that provides access to many system administration operations.
-
CAP_SYS_TTY_CONFIG
Before performing a privileged operation, a device driver should check
that the calling process has the appropriate capability with the
capable function (defined in
<sys/sched.h>):
int capable(int capability);
In the scull sample driver, any user is allowed to query the quantum and quantum set sizes. Only privileged users, however, may change those values, since inappropriate values could badly affect system performance. When needed, the scull implementation of ioctl checks a user’s privilege level as follows:
if (! capable (CAP_SYS_ADMIN)) return -EPERM;
In the absence of a more specific capability for this task,
CAP_SYS_ADMIN was chosen for this test.
The scull implementation of ioctl only transfers the configurable parameters of the device and turns out to be as easy as the following:
switch(cmd) {
#ifdef SCULL_DEBUG
case SCULL_IOCHARDRESET:
/*
* reset the counter to 1, to allow unloading in case
* of problems. Use 1, not 0, because the invoking
* process has the device open.
*/
while (MOD_IN_USE)
MOD_DEC_USE_COUNT;
MOD_INC_USE_COUNT;
/* don't break: fall through and reset things */
#endif /* SCULL_DEBUG */
case SCULL_IOCRESET:
scull_quantum = SCULL_QUANTUM;
scull_qset = SCULL_QSET;
break;
case SCULL_IOCSQUANTUM: /* Set: arg points to the value */
if (! capable (CAP_SYS_ADMIN))
return -EPERM;
ret = __get_user(scull_quantum, (int *)arg);
break;
case SCULL_IOCTQUANTUM: /* Tell: arg is the value */
if (! capable (CAP_SYS_ADMIN))
return -EPERM;
scull_quantum = arg;
break;
case SCULL_IOCGQUANTUM: /* Get: arg is pointer to result */
ret = __put_user(scull_quantum, (int *)arg);
break;
case SCULL_IOCQQUANTUM: /* Query: return it (it's positive) */
return scull_quantum;
case SCULL_IOCXQUANTUM: /* eXchange: use arg as pointer */
if (! capable (CAP_SYS_ADMIN))
return -EPERM;
tmp = scull_quantum;
ret = __get_user(scull_quantum, (int *)arg);
if (ret == 0)
ret = __put_user(tmp, (int *)arg);
break;
case SCULL_IOCHQUANTUM: /* sHift: like Tell + Query */
if (! capable (CAP_SYS_ADMIN))
return -EPERM;
tmp = scull_quantum;
scull_quantum = arg;
return tmp;
default: /* redundant, as cmd was checked against MAXNR */
return -ENOTTY;
}
return ret;
scull also includes six entries that act on
scull_qset. These entries are identical to the ones
for scull_quantum and are not worth showing in
print.
The six ways to pass and receive arguments look like the following from the caller’s point of view (i.e., from user space):
int quantum; ioctl(fd,SCULL_IOCSQUANTUM, &quantum); ioctl(fd,SCULL_IOCTQUANTUM, quantum); ioctl(fd,SCULL_IOCGQUANTUM, &quantum); quantum = ioctl(fd,SCULL_IOCQQUANTUM); ioctl(fd,SCULL_IOCXQUANTUM, &quantum); quantum = ioctl(fd,SCULL_IOCHQUANTUM, quantum);
Of course, a normal driver would not implement such a mix of calling modes in one place. We have done so here only to demonstrate the different ways in which things could be done. Normally, however, data exchanges would be consistently performed, either through pointers (more common) or by value (less common), and mixing of the two techniques would be avoided.
Sometimes controlling the device is better accomplished by writing control sequences to the device itself. This technique is used, for example, in the console driver, where so-called escape sequences are used to move the cursor, change the default color, or perform other configuration tasks. The benefit of implementing device control this way is that the user can control the device just by writing data, without needing to use (or sometimes write) programs built just for configuring the device.
For example, the setterm program acts on the console (or another terminal) configuration by printing escape sequences. This behavior has the advantage of permitting the remote control of devices. The controlling program can live on a different computer than the controlled device, because a simple redirection of the data stream does the configuration job. You’re already used to this with ttys, but the technique is more general.
The drawback of controlling by printing is that it adds policy constraints to the device; for example, it is viable only if you are sure that the control sequence can’t appear in the data being written to the device during normal operation. This is only partly true for ttys. Although a text display is meant to display only ASCII characters, sometimes control characters can slip through in the data being written and can thus affect the console setup. This can happen, for example, when you issue grep on a binary file; the extracted lines can contain anything, and you often end up with the wrong font on your console.[25]
Controlling by write is definitely the way to go for those devices that don’t transfer data but just respond to commands, such as robotic devices.
For instance, a driver written for fun by one of your authors moves a camera on two axes. In this driver, the “device” is simply a pair of old stepper motors, which can’t really be read from or written to. The concept of “sending a data stream” to a stepper motor makes little or no sense. In this case, the driver interprets what is being written as ASCII commands and converts the requests to sequences of impulses that manipulate the stepper motors. The idea is similar, somewhat, to the AT commands you send to the modem in order to set up communication, the main difference being that the serial port used to communicate with the modem must transfer real data as well. The advantage of direct device control is that you can use cat to move the camera without writing and compiling special code to issue the ioctl calls.
When writing command-oriented drivers, there’s no reason to implement the ioctl method. An additional command in the interpreter is easier to implement and use.
Sometimes, though, you might choose to act the other way around: instead of making write into an interpreter and avoiding ioctl, you might choose to avoid write altogether and use ioctl commands exclusively, while accompanying the driver with a specific command-line tool to send those commands to the driver. This approach moves the complexity from kernel space to user space, where it may be easier to deal with, and helps keep the driver small while denying use of simple cat or echo commands.
[24] A fragment of program code is said to be atomic when it will always be executed as though it were a single instruction, without the possibility of the processor being interrupted and something happening in between (such as somebody else’s code running).
[25] CTRL-N sets the alternate font, which is made up of graphic symbols and thus isn’t a friendly font for typing input to your shell; if you encounter this problem, echo a CTRL-O character to restore the primary font.
Get Linux Device Drivers, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
