From: Tobias Waldekranz <tobias@waldekranz.com>
To: Sughosh Ganu <sughosh.ganu@linaro.org>, u-boot@lists.denx.de
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>,
Anton Antonov <Anton.Antonov@arm.com>,
Bin Meng <bmeng@tinylab.org>,
Sughosh Ganu <sughosh.ganu@linaro.org>
Subject: Re: [PATCH v3 4/5] blkmap: store type of blkmap device in corresponding structure
Date: Mon, 20 Jan 2025 13:25:39 +0100 [thread overview]
Message-ID: <877c6p7juk.fsf@waldekranz.com> (raw)
In-Reply-To: <20250120105045.1281262-5-sughosh.ganu@linaro.org>
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.
Looking at the pmem patch that follows this one, I am not able to find
anything that would motivate restricting the functionality either.
next prev parent reply other threads:[~2025-01-20 12:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-20 10:50 [PATCH v3 0/5] Add pmem node for preserving distro ISO's Sughosh Ganu
2025-01-20 10:50 ` [PATCH v3 1/5] fdt: add support for adding pmem nodes Sughosh Ganu
2025-01-20 12:31 ` Heinrich Schuchardt
2025-01-20 14:02 ` Sughosh Ganu
2025-01-24 10:56 ` Sughosh Ganu
2025-01-20 10:50 ` [PATCH v3 2/5] efi_loader: add a function to remove memory from the EFI map Sughosh Ganu
2025-01-20 12:36 ` Heinrich Schuchardt
2025-01-20 10:50 ` [PATCH v3 3/5] efi_loader: preserve installer images in pmem Sughosh Ganu
2025-01-20 10:50 ` [PATCH v3 4/5] blkmap: store type of blkmap device in corresponding structure Sughosh Ganu
2025-01-20 12:25 ` Tobias Waldekranz [this message]
2025-01-20 14:00 ` Sughosh Ganu
2025-01-20 14:36 ` Tobias Waldekranz
2025-01-20 15:40 ` Sughosh Ganu
2025-01-20 16:20 ` Tobias Waldekranz
2025-01-20 19:25 ` Sughosh Ganu
2025-01-20 21:36 ` Tobias Waldekranz
2025-01-21 6:43 ` Sughosh Ganu
2025-01-21 15:54 ` Ilias Apalodimas
2025-01-21 16:02 ` Sughosh Ganu
2025-01-21 21:47 ` Ilias Apalodimas
2025-01-22 6:38 ` Sughosh Ganu
2025-01-20 10:50 ` [PATCH v3 5/5] blkmap: add pmem nodes for blkmap mem mapping devices Sughosh Ganu
2025-01-24 11:39 ` [PATCH v3 0/5] Add pmem node for preserving distro ISO's Ilias Apalodimas
2025-01-24 19:18 ` Tom Rini
2025-01-24 21:19 ` Tobias Waldekranz
2025-01-27 6:46 ` Sughosh Ganu
2025-01-27 11:44 ` Ilias Apalodimas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877c6p7juk.fsf@waldekranz.com \
--to=tobias@waldekranz.com \
--cc=Anton.Antonov@arm.com \
--cc=bmeng@tinylab.org \
--cc=ilias.apalodimas@linaro.org \
--cc=sjg@chromium.org \
--cc=sughosh.ganu@linaro.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.