From: Daniel Golle <daniel@makrotopia.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Richard Weinberger <richard@nod.at>,
Matthew Wilcox <willy@infradead.org>,
Jens Axboe <axboe@kernel.dk>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Chaitanya Kulkarni <kch@nvidia.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] init: move block device helpers from init/do_mounts.c
Date: Sat, 19 Nov 2022 16:03:11 +0000 [thread overview]
Message-ID: <Y3j+Pzy1JpqG8Yd8@makrotopia.org> (raw)
In-Reply-To: <Y3XM62P7CaeKXFsz@infradead.org>
Hi Christoph,
On Wed, Nov 16, 2022 at 09:55:55PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 17, 2022 at 12:42:43AM +0000, Daniel Golle wrote:
> > In init/do_mounts.c there are helper functions devt_from_partuuid,
> > devt_from_partlabel and devt_from_devname. In order to make these
> > functions available to other users, move them to block/bdev.c.
>
> Yes, they should be moved and I have an old patch to do this a bit
> smarter. But that doesn't mean anyone else should call them.
I have followed your advise and implemented a "real" block driver
stacking on top of an existing block device to expose uImage.FIT
filesystem subimages as block devices. It mangles any bio submitted to
it and re-submits the bio with changed bi_bdev and sector offset added
to bi_iter.bi_sector for all list elements.
That works, but has slightly less utility value than the partition
parser approach as in this way I cannot easily populate the PARTNAME
uevent which can later help userspace to identify a device by the FIT
subimage name -- I'd have to either invent a new bus_type or
device_type, both seem inappropriate and have unwanted side effects.
Or am I missing something and there is a way to use add_uevent_var()
for a disk_type device?
In exchange, instead of using the PARTNAME= uevent var, I can now
freely name the device node by setting the disk_name string in
struct gendisk. While this doesn't offer the same amount of freedom, it
is sufficient for our use-case.
However, I don't see a way to avoid using (or duplicating)
devt_from_devname() to select the lower device somehow without having
to probe and parse *all* block devices present (which is, from what I
understood, what you want to avoid, and I agree that it is more safe to
not do that...)
Can you or anyone give some advise on how this should be done?
As block partitions are not present in device tree, using a cmdline
argument (with similar semantics to 'root=') specifying the lower block
device seems unavoidable.
Also note that due to libfdt not exporting symbols, the driver
currently cannot be built as a module. Hence, I would either need to
export most of libfdt API or only allow the driver to be built-into the
kernel. I don't see a problem with having it always built-in.
Yet another (imho not terrible) problem is removal of the lower device.
Many of the supported SBC use a micro SD card to boot, which can be
removed by the user while the system is running (which is generally not
a good idea, but anyway). For partitions this is handled automatically
by blk_drop_partitions() called directly from genhd.c.
I'm currently playing with doing something similar using the bus device
removal notification, but it doesn't seem to work for all cases, e.g.
mmcblk device do not seem to have the ->bus pointer populated at all
(ie. disk_to_dev(disk)->bus == NULL for mmcblk devices).
Any ideas regarding that?
Thank you for your advise!
Daniel
next prev parent reply other threads:[~2022-11-19 16:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 0:42 [RFC PATCH 0/4] block: uImage.FIT filesystem image mapper Daniel Golle
2022-11-17 0:42 ` [RFC PATCH 1/4] init: move block device helpers from init/do_mounts.c Daniel Golle
2022-11-17 5:55 ` Christoph Hellwig
2022-11-19 16:03 ` Daniel Golle [this message]
2022-11-22 12:37 ` Christoph Hellwig
2022-12-09 17:00 ` Daniel Golle
2022-12-12 9:03 ` Christoph Hellwig
2022-12-12 11:02 ` Daniel Golle
2022-12-13 6:48 ` Christoph Hellwig
2022-12-13 12:45 ` Daniel Golle
2022-12-14 16:43 ` Christoph Hellwig
2022-12-14 20:01 ` Daniel Golle
2022-12-15 8:09 ` Christoph Hellwig
2023-03-30 14:43 ` Daniel Golle
2022-11-17 0:43 ` [RFC PATCH 2/4] block: add new flag to add partitions read-only Daniel Golle
2022-11-17 0:44 ` [RFC PATCH 3/4] blkdev: add function to add named read-only partitions Daniel Golle
2022-11-17 5:56 ` Christoph Hellwig
2022-11-17 17:12 ` Daniel Golle
2022-11-17 0:45 ` [RFC PATCH 4/4] block: add uImage.FIT block partition driver Daniel Golle
2022-11-17 5:58 ` Christoph Hellwig
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=Y3j+Pzy1JpqG8Yd8@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=richard@nod.at \
--cc=willy@infradead.org \
--cc=wsa+renesas@sang-engineering.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®