include/kunit/device.h
Source file repositories/reference/linux-study-clean/include/kunit/device.h
File Facts
- System
- Linux kernel
- Corpus path
include/kunit/device.h- Extension
.h- Size
- 2833 bytes
- Lines
- 81
- Domain
- Repository Root And Misc
- Bucket
- include
- Inferred role
- Repository Root And Misc: operation-table or driver-model contract
- Status
- pattern implementation candidate
Why This File Exists
Top-level or miscellaneous repository surface. Use this as map coverage unless a later manual pass promotes the file into a deeper subsystem dossier.
- Top-level or miscellaneous repository surface. Use this as map coverage unless a later manual pass promotes the file into a deeper subsystem dossier.
- 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
kunit/test.h
Detected Declarations
struct devicestruct device_driver
Annotated Snippet
struct device_driver;
/**
* kunit_driver_create() - Create a struct device_driver attached to the kunit_bus
* @test: The test context object.
* @name: The name to give the created driver.
*
* Creates a struct device_driver attached to the kunit_bus, with the name @name.
* This driver will automatically be cleaned up on test exit.
*
* Return: a stub struct device_driver, managed by KUnit, with the name @name.
*/
struct device_driver *kunit_driver_create(struct kunit *test, const char *name);
/**
* kunit_device_register() - Create a struct device for use in KUnit tests
* @test: The test context object.
* @name: The name to give the created device.
*
* Creates a struct kunit_device (which is a struct device) with the given name,
* and a corresponding driver. The device and driver will be cleaned up on test
* exit, or when kunit_device_unregister is called. See also
* kunit_device_register_with_driver, if you wish to provide your own
* struct device_driver.
*
* Return: a pointer to a struct device which will be cleaned up when the test
* exits, or an error pointer if the device could not be allocated or registered.
*/
struct device *kunit_device_register(struct kunit *test, const char *name);
/**
* kunit_device_register_with_driver() - Create a struct device for use in KUnit tests
* @test: The test context object.
* @name: The name to give the created device.
* @drv: The struct device_driver to associate with the device.
*
* Creates a struct kunit_device (which is a struct device) with the given
* name, and driver. The device will be cleaned up on test exit, or when
* kunit_device_unregister is called. See also kunit_device_register, if you
* wish KUnit to create and manage a driver for you.
*
* Return: a pointer to a struct device which will be cleaned up when the test
* exits, or an error pointer if the device could not be allocated or registered.
*/
struct device *kunit_device_register_with_driver(struct kunit *test,
const char *name,
const struct device_driver *drv);
/**
* kunit_device_unregister() - Unregister a KUnit-managed device
* @test: The test context object which created the device
* @dev: The device.
*
* Unregisters and destroys a struct device which was created with
* kunit_device_register or kunit_device_register_with_driver. If KUnit created
* a driver, cleans it up as well.
*/
void kunit_device_unregister(struct kunit *test, struct device *dev);
#endif
#endif
Annotation
- Immediate include surface: `kunit/test.h`.
- Detected declarations: `struct device`, `struct device_driver`.
- Atlas domain: Repository Root And Misc / include.
- 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.