[PATCH v3 4/5] blkmap: store type of blkmap device in corresponding structure

[Sughosh Ganu]

On Mon, 20 Jan 2025 at 17:55, Tobias Waldekranz <tobias at waldekranz.com> wrote:
>
> On mån, jan 20, 2025 at 16:20, Sughosh Ganu <sughosh.ganu at 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
with slices of different types? Would that not contravene with the
idea of a block device associating with a blkmap?

>
> 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.

-sughosh