include/linux/comedi/comedi_pci.h

File Facts

System

Linux kernel

Corpus path

include/linux/comedi/comedi_pci.h

Extension

.h

Size

1850 bytes

Lines

57

Domain

Core OS

Bucket

Core Kernel Interface

Inferred role

Core OS: operation-table or driver-model contract

Status

pattern implementation candidate

Why This File Exists

Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.

• Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
• 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

• linux/pci.h
• linux/comedi/comedidev.h

Detected Declarations

• No top-level syscall, struct, function, initcall, or export declaration detected by the generator.

Annotated Snippet

struct pci_driver *pci_driver);
void comedi_pci_driver_unregister(struct comedi_driver *comedi_driver,
				  struct pci_driver *pci_driver);

/**
 * module_comedi_pci_driver() - Helper macro for registering a comedi PCI driver
 * @__comedi_driver: comedi_driver struct
 * @__pci_driver: pci_driver struct
 *
 * Helper macro for comedi PCI drivers which do not do anything special
 * in module init/exit. This eliminates a lot of boilerplate. Each
 * module may only use this macro once, and calling it replaces
 * module_init() and module_exit()
 */
#define module_comedi_pci_driver(__comedi_driver, __pci_driver) \
	module_driver(__comedi_driver, comedi_pci_driver_register, \
			comedi_pci_driver_unregister, &(__pci_driver))

#endif /* _COMEDI_PCI_H */

Annotation

• Immediate include surface: `linux/pci.h`, `linux/comedi/comedidev.h`.
• Atlas domain: Core OS / Core Kernel Interface.
• 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.