Linux Device Drivers (3rd Edition) [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Linux Device Drivers (3rd Edition) [Electronic resources] - نسخه متنی

Jonathan Corbet, Greg Kroah-Hartman, Alessandro Rubini

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








Chapter 14. The Linux Device Model


One of the stated goals for the 2.5 development cycle was the
creation of a unified device model for the kernel. Previous kernels had no single
data structure to which they could turn to obtain information about
how the system is put together. Despite this lack of information,
things worked well for some time. The demands of newer systems, with
their more complicated topologies and need to support features such
as power management, made it clear, however, that a general
abstraction describing the structure of the system was needed.

The 2.6 device model provides that abstraction. It is now used within
the kernel to support a wide variety of tasks, including:

Power management and system shutdown


These require an



understanding of the system's structure. For
example, a USB host adaptor cannot be shut down before dealing with
all of the devices connected to that adaptor. The device model
enables a traversal of the system's hardware in the
right order.


Communications with user space


The implementation of the
sysfs virtual filesystem is tightly tied into the device model and
exposes the structure represented by it. The provision of information
about the system to user space and knobs for changing operating
parameters is increasingly done through sysfs and, therefore, through
the device model.


Hotpluggable devices


Computer
hardware

is increasingly dynamic; peripherals can come and go at the whim of
the user. The hotplug mechanism used within the kernel to handle and
(especially) communicate with user space about the plugging and
unplugging of devices is managed through the device model.


Device classes


Many parts of the system
have

little interest in how devices are connected, but they need to know
what kinds of devices are available. The device model includes a
mechanism for assigning devices to classes,
which describe those devices at a higher, functional level and allow
them to be discovered from user space.


Object lifecycles


Many of the

functions
described above, including hotplug support and sysfs, complicate the
creation and manipulation of objects created within the kernel. The
implementation of the device model required the creation of a set of
mechanisms for dealing with object lifecycles, their relationships to
each other, and their representation in user space.



The Linux device model is a complex data structure. For example,
consider Chapter 14, which
shows (in simplified form) a tiny piece of the device model structure
associated with a USB mouse. Down the center of the diagram, we see
the part of the core "devices" tree
that shows how the mouse is connected to the system. The
"bus" tree tracks what is connected
to each bus, while the subtree under
"classes" concerns itself with the
functions provided by the devices, regardless of how they are
connected. The device model tree on even a simple system contains
hundreds of nodes like those shown in the diagram; it is a difficult
data structure to visualize as a whole.


Figure 14-1. A small piece of the device model

For the most part, the Linux device model code takes care of all
these considerations without imposing itself upon driver authors. It
sits mostly in the background; direct interaction with the device
model is generally handled by bus-level logic and various other
kernel subsystems. As a result, many driver authors can ignore the
device model entirely, and trust it to take care of itself.

There are times, however, when an understanding of the device model
is a good thing to have. There are times when the device model
"leaks out" from behind the other
layers; for example, the generic DMA code (which we encounter in
Chapter 15) works with
struct device. You may want to use some of the
capabilities provided by the device model, such as the reference
counting and related features provided by kobjects. Communication
with user space via sysfs is also a device model function; this
chapter explains how that communication works.

We start, however, with a bottom-up presentation of the device model.
The complexity of the device model makes it hard to understand by
starting with a high-level view. Our hope is that, by showing how the
low-level device components work, we can prepare you for the
challenge of grasping how those components are used to build the
larger structure.

For many readers, this chapter can be treated as advanced material
that need not be read the first time through. Those who are
interested in how the Linux device model works are encouraged to
press ahead, however, as we get into the low-level details.


    / 202