On Mon, 20 Jan 2025 at 20:06, Tobias Waldekranz tobias@waldekranz.com wrote:
On mån, jan 20, 2025 at 19:30, Sughosh Ganu sughosh.ganu@linaro.org wrote:
On Mon, 20 Jan 2025 at 17:55, Tobias Waldekranz tobias@waldekranz.com wrote:
On mån, jan 20, 2025 at 16:20, Sughosh Ganu sughosh.ganu@linaro.org wrote:
Add information about the type of blkmap device in the blkmap structure. Currently, the blkmap device is used for mapping to either a memory based block device, or another block device (linear mapping). Put information in the blkmap structure to identify if it is associated with a memory or linear mapped device. Which can then be used to take specific action based on the type of blkmap device.
Is this restriction really necessary? Why should it not be possible to setup a block map like this:
myblkmap: .--------. .-----. | slice0 +------> RAM | :--------: '-----' .-------. | slice1 +------------------> eMMC0 | :--------: .-------. '-------' | slice2 +------> eMMC1 | '........' '-------'
Linux's "device mapper", after which blkmaps are modeled, works in this way. I.e. a blkmap is just a collection of slices, and it is up to each slice how its data is provided, meaning that the user is free to compose their virtual block device in whatever way they need.
The blkmap structure, the way it is designed, is pointing to the underlying block device. How can a single blkmap then be associated
The `struct udevice *blk` from `struct blkmap` is a reference to the block device which represents the block map itself ("myblkmap" in the picture above), not any lower device.
Okay. I got confused with the comment associated with that member, which says, "Underlying block device". This I interpreted to be the block device that is associated with the blkmap structure.
with slices of different types? Would that not contravene with the idea of a block device associating with a blkmap?
For slices which are linear mappings (and are thus backed by some other underlying block device), their reference to that lower device ("eMMC0" and "eMMC1" above) is stored in the `struct udevice *blk` member of `struct blkmap_linear`.
Okay. But then, the computation of the blocksize seems to be happening at the blkmap device level, which again implies having the same set of slices associated with the blkmap. Any reason why the blksize is not taken from the block device associated with that slice? That would make it clear that the slice mapping type is independent from the parent blkmap device.
Slices which are backed by memory does not have any reference to a lower device, but merely a pointer to the start of the mapping - `void *addr` in `struct blkmap_mem`.
The overarching idea is that the block map does not have to know anything about the implementation of how any individual slice chooses to provide its data. It only knows about their sizes and offsets. Based on that information, it simply routes incoming read/write requests to the correct slice.
Okay. I think, for my solution, I will just need to move type identification to the slice, instead of the blkmap device.
Looking at the pmem patch that follows this one, I am not able to find anything that would motivate restricting the functionality either.
The subsequent patch is adding the persistent memory node to the device-tree. The pmem node that is to be added is the memory mapped blkmap device. The logic does check for the type of the blkmap device and then proceeds to add the pmem node only for the memory mapped blkmaps.
Sorry I am confused. Why do you need a block map device to add the pmem node to the device tree?
This is needed to include the RAM based block device information in the device-tree as pmem node. The OS installer then uses this pmem device as the block device which contains the installation packages, and proceeds with the OS installation.
-sughosh