Documentation/driver-api/driver-model/overview.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/driver-model/overview.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/driver-model/overview.rst
Extension
.rst
Size
4838 bytes
Lines
125
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

struct pci_dev {
	...

	struct device dev;     /* Generic device interface */
	...
  };

Note first that the struct device dev within the struct pci_dev is
statically allocated. This means only one allocation on device discovery.

Note also that that struct device dev is not necessarily defined at the
front of the pci_dev structure.  This is to make people think about what
they're doing when switching between the bus driver and the global driver,
and to discourage meaningless and incorrect casts between the two.

The PCI bus layer freely accesses the fields of struct device. It knows about
the structure of struct pci_dev, and it should know the structure of struct
device. Individual PCI device drivers that have been converted to the current
driver model generally do not and should not touch the fields of struct device,
unless there is a compelling reason to do so.

The above abstraction prevents unnecessary pain during transitional phases.
If it were not done this way, then when a field was renamed or removed, every
downstream driver would break.  On the other hand, if only the bus layer
(and not the device layer) accesses the struct device, it is only the bus
layer that needs to change.


User Interface
~~~~~~~~~~~~~~

By virtue of having a complete hierarchical view of all the devices in the
system, exporting a complete hierarchical view to userspace becomes relatively
easy. This has been accomplished by implementing a special purpose virtual
file system named sysfs.

Almost all mainstream Linux distros mount this filesystem automatically; you
can see some variation of the following in the output of the "mount" command::

  $ mount
  ...
  none on /sys type sysfs (rw,noexec,nosuid,nodev)
  ...
  $

The auto-mounting of sysfs is typically accomplished by an entry similar to
the following in the /etc/fstab file::

  none     	/sys	sysfs    defaults	  	0 0

or something similar in the /lib/init/fstab file on Debian-based systems::

  none            /sys    sysfs    nodev,noexec,nosuid    0 0

If sysfs is not automatically mounted, you can always do it manually with::

	# mount -t sysfs sysfs /sys

Whenever a device is inserted into the tree, a directory is created for it.
This directory may be populated at each layer of discovery - the global layer,
the bus layer, or the device layer.

The global layer currently creates two files - 'name' and 'power'. The
former only reports the name of the device. The latter reports the
current power state of the device. It will also be used to set the current
power state.

The bus layer may also create files for the devices it finds while probing the
bus. For example, the PCI layer currently creates 'irq' and 'resource' files
for each PCI device.

Annotation

Implementation Notes