IBM 10 SP1 EAL4 Manuale Utente
5.9 Device drivers
A device driver is a software layer that makes a hardware device respond to a well-defined programming
interface. The kernel interacts with the device only through these well-defined interfaces. For detailed
information about device drivers, see Linux Device Drivers, 2nd Edition, by Alessandro Rubini and Jonathan
Corbet.
The TOE supports many different I/O devices, such as disk drives, tape drives, and network adapters. Each of
these hardware devices can have its own methods of handling data.
The device driver subsystem provides a layer of abstraction to other kernel subsystems, so they can interact
with hardware devices without being cognizant of their internal workings. Each supported hardware device
has a device driver that is loaded into the kernel during system initialization. The device driver subsystem
provides access to these supported hardware devices from user space through special device files in the /dev
interface. The kernel interacts with the device only through these well-defined interfaces. For detailed
information about device drivers, see Linux Device Drivers, 2nd Edition, by Alessandro Rubini and Jonathan
Corbet.
The TOE supports many different I/O devices, such as disk drives, tape drives, and network adapters. Each of
these hardware devices can have its own methods of handling data.
The device driver subsystem provides a layer of abstraction to other kernel subsystems, so they can interact
with hardware devices without being cognizant of their internal workings. Each supported hardware device
has a device driver that is loaded into the kernel during system initialization. The device driver subsystem
provides access to these supported hardware devices from user space through special device files in the /dev
directory. Valid operations on the device-special files are initialized to point to appropriate functions in the
device driver for the corresponding hardware device.
Other kernel subsystems, such as File, I/O, and the Networking subsystems, have direct access to these device
driver functions because the device driver is loaded into the kernel space at system initialization time. The
File, I/O, and Networking subsystems interact with these device driver functions to drive the hardware device.
For example, when a file is to be written to a hard drive, data blocks corresponding to the file are queued in
the buffer cache of the File and I/O subsystem. From there, the File and I/O subsystem invokes the function
to flush the data to the desired device. The device driver corresponding to that device then takes that data and
invokes the device-specific functions to transfer the data to the hard drive. Similarly, the Networking
subsystem interacts with the device driver subsystem to transfer networking traffic to a network adapter. The
physical layer of the networking stack invokes appropriate functions to send and receive networking packets
through a network adapter. The device driver corresponding to the network adapter invokes appropriate
adapter-specific functions to send or receive network packets through the network adapter.
Device drivers provide a generic interface to the rest of the kernel consisting of device methods for the start-
up of a device (open method), shutdown of a device (release method), flushing contents of internal buffers
(flush method), reading data from the device (read method), writing data to the device (write method), and
performing device-specific control operations (ioctl method).
SLES running on System p and System z supports virtual devices. From the perspective of SLES, these
devices are treated no differently than other devices. That is, the SLES kernel thinks that it is directly
controlling devices. However, the z/VM on System z map these virtual devices to real devices, allowing
SLES access to devices supported by z/VM when running on System z. The following subsections briefly
describe this virtualization of I/O, followed by brief descriptions of device drivers for character and block
devices.
device driver for the corresponding hardware device.
Other kernel subsystems, such as File, I/O, and the Networking subsystems, have direct access to these device
driver functions because the device driver is loaded into the kernel space at system initialization time. The
File, I/O, and Networking subsystems interact with these device driver functions to drive the hardware device.
For example, when a file is to be written to a hard drive, data blocks corresponding to the file are queued in
the buffer cache of the File and I/O subsystem. From there, the File and I/O subsystem invokes the function
to flush the data to the desired device. The device driver corresponding to that device then takes that data and
invokes the device-specific functions to transfer the data to the hard drive. Similarly, the Networking
subsystem interacts with the device driver subsystem to transfer networking traffic to a network adapter. The
physical layer of the networking stack invokes appropriate functions to send and receive networking packets
through a network adapter. The device driver corresponding to the network adapter invokes appropriate
adapter-specific functions to send or receive network packets through the network adapter.
Device drivers provide a generic interface to the rest of the kernel consisting of device methods for the start-
up of a device (open method), shutdown of a device (release method), flushing contents of internal buffers
(flush method), reading data from the device (read method), writing data to the device (write method), and
performing device-specific control operations (ioctl method).
SLES running on System p and System z supports virtual devices. From the perspective of SLES, these
devices are treated no differently than other devices. That is, the SLES kernel thinks that it is directly
controlling devices. However, the z/VM on System z map these virtual devices to real devices, allowing
SLES access to devices supported by z/VM when running on System z. The following subsections briefly
describe this virtualization of I/O, followed by brief descriptions of device drivers for character and block
devices.
5.9.1 I/O virtualization on System z
SLES runs on System z as a guest of the z/VM operating system. The z/VM operating system can provide
each end user with an individual working environment known as virtual machine. Virtual machines
communicate with the outside world through virtual devices. The Control Program transparently handles
mapping of virtual to real devices and resources.
each end user with an individual working environment known as virtual machine. Virtual machines
communicate with the outside world through virtual devices. The Control Program transparently handles
mapping of virtual to real devices and resources.
5.9.1.1 Interpretive-execution facility
The interpretive-execution facility provides complete handling of many aspects of the architecture of an
interpreted machine or, when such handling is not provided, presents virtual-machine status in a form
convenient for further support-program processing.
The interpreted machine is viewed as a virtual system called the guest. The term host refers to the real
machine and to the control program, which both manages real-machine resources, and provides services to the
interpreted machine or, when such handling is not provided, presents virtual-machine status in a form
convenient for further support-program processing.
The interpreted machine is viewed as a virtual system called the guest. The term host refers to the real
machine and to the control program, which both manages real-machine resources, and provides services to the
152