drivers/md/persistent-data/dm-block-manager.h
Source file repositories/reference/linux-study-clean/drivers/md/persistent-data/dm-block-manager.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/md/persistent-data/dm-block-manager.h- Extension
.h- Size
- 4269 bytes
- Lines
- 139
- Domain
- Driver Families
- Bucket
- drivers/md
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/types.hlinux/blkdev.h
Detected Declarations
struct dm_blockstruct dm_block_managerstruct dm_block_validator
Annotated Snippet
struct dm_block_validator {
const char *name;
void (*prepare_for_write)(const struct dm_block_validator *v,
struct dm_block *b, size_t block_size);
/*
* Return 0 if the checksum is valid or < 0 on error.
*/
int (*check)(const struct dm_block_validator *v,
struct dm_block *b, size_t block_size);
};
/*----------------------------------------------------------------*/
/*
* You can have multiple concurrent readers or a single writer holding a
* block lock.
*/
/*
* dm_bm_lock() locks a block and returns through @result a pointer to
* memory that holds a copy of that block. If you have write-locked the
* block then any changes you make to memory pointed to by @result will be
* written back to the disk sometime after dm_bm_unlock is called.
*/
int dm_bm_read_lock(struct dm_block_manager *bm, dm_block_t b,
const struct dm_block_validator *v,
struct dm_block **result);
int dm_bm_write_lock(struct dm_block_manager *bm, dm_block_t b,
const struct dm_block_validator *v,
struct dm_block **result);
/*
* The *_try_lock variants return -EWOULDBLOCK if the block isn't
* available immediately.
*/
int dm_bm_read_try_lock(struct dm_block_manager *bm, dm_block_t b,
const struct dm_block_validator *v,
struct dm_block **result);
/*
* Use dm_bm_write_lock_zero() when you know you're going to
* overwrite the block completely. It saves a disk read.
*/
int dm_bm_write_lock_zero(struct dm_block_manager *bm, dm_block_t b,
const struct dm_block_validator *v,
struct dm_block **result);
void dm_bm_unlock(struct dm_block *b);
/*
* It's a common idiom to have a superblock that should be committed last.
*
* @superblock should be write-locked on entry. It will be unlocked during
* this function. All dirty blocks are guaranteed to be written and flushed
* before the superblock.
*
* This method always blocks.
*/
int dm_bm_flush(struct dm_block_manager *bm);
/*
* Request data is prefetched into the cache.
*/
void dm_bm_prefetch(struct dm_block_manager *bm, dm_block_t b);
/*
* Switches the bm to a read only mode. Once read-only mode
* has been entered the following functions will return -EPERM.
*
* dm_bm_write_lock
* dm_bm_write_lock_zero
* dm_bm_flush_and_unlock
*
* Additionally you should not use dm_bm_unlock_move, however no error will
* be returned if you do.
*/
bool dm_bm_is_read_only(struct dm_block_manager *bm);
void dm_bm_set_read_only(struct dm_block_manager *bm);
void dm_bm_set_read_write(struct dm_block_manager *bm);
u32 dm_bm_checksum(const void *data, size_t len, u32 init_xor);
/*----------------------------------------------------------------*/
#endif /* _LINUX_DM_BLOCK_MANAGER_H */
Annotation
- Immediate include surface: `linux/types.h`, `linux/blkdev.h`.
- Detected declarations: `struct dm_block`, `struct dm_block_manager`, `struct dm_block_validator`.
- Atlas domain: Driver Families / drivers/md.
- Implementation status: source 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.