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

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

File Facts

System: Linux kernel
Corpus path: Documentation/driver-api/driver-model/porting.rst
Extension: .rst
Size: 13463 bytes
Lines: 449
Domain: Support Tooling And Documentation
Bucket: Documentation
Inferred role: Support Tooling And Documentation: operation-table or driver-model contract
Status: pattern implementation candidate

Why This File Exists

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

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Defines an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.

Dependency Surface

No C-style include directives detected by the generator.

Detected Declarations

struct pci_dev
struct pci_driver
function module_init
function to_pci_dev
function pci_device_remove
module init pci_driver_init
export pci_bus_type

Annotated Snippet

- Define a struct bus_type for the bus driver::

    struct bus_type pci_bus_type = {
          .name           = "pci",
    };


- Register the bus type.

  This should be done in the initialization function for the bus type,
  which is usually the module_init(), or equivalent, function::

    static int __init pci_driver_init(void)
    {
            return bus_register(&pci_bus_type);
    }

    subsys_initcall(pci_driver_init);


  The bus type may be unregistered (if the bus driver may be compiled
  as a module) by doing::

     bus_unregister(&pci_bus_type);


- Export the bus type for others to use.

  Other code may wish to reference the bus type, so declare it in a
  shared header file and export the symbol.

From include/linux/pci.h::

  extern struct bus_type pci_bus_type;


From file the above code appears in::

  EXPORT_SYMBOL(pci_bus_type);



- This will cause the bus to show up in /sys/bus/pci/ with two
  subdirectories: 'devices' and 'drivers'::

    # tree -d /sys/bus/pci/
    /sys/bus/pci/
    |-- devices
    `-- drivers



Step 2: Registering Devices.

struct device represents a single device. It mainly contains metadata
describing the relationship the device has to other entities.


- Embed a struct device in the bus-specific device type::


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

  It is recommended that the generic device not be the first item in
  the struct to discourage programmers from doing mindless casts
  between the object types. Instead macros, or inline functions,

Annotation

Detected declarations: `struct pci_dev`, `struct pci_driver`, `function module_init`, `function to_pci_dev`, `function pci_device_remove`, `module init pci_driver_init`, `export pci_bus_type`.
Atlas domain: Support Tooling And Documentation / Documentation.
Implementation status: pattern implementation candidate.

Implementation Notes

This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.