From: Christoph Hellwig <hch@infradead.org>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Christoph Hellwig <hch@infradead.org>,
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: Tue, 22 Nov 2022 04:37:08 -0800 [thread overview]
Message-ID: <Y3zCdJr5dKsADsnM@infradead.org> (raw)
In-Reply-To: <Y3j+Pzy1JpqG8Yd8@makrotopia.org>
On Sat, Nov 19, 2022 at 04:03:11PM +0000, Daniel Golle wrote:
> 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?
You're not exposing a partition here - this is an image format that
sits in a partition and we should not pretend that is a partition.
> 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?
Just set the block driver up from an initramfs, like we do for all
modern stackable drivers.
> 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).
I have WIP patches that allow the claimer of a block device get
resize and removal notification. It's not going to land for 6.2,
but I hope I have it ready in time for the next merge window.
next prev parent reply other threads:[~2022-11-22 12:37 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
2022-11-22 12:37 ` Christoph Hellwig [this message]
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=Y3zCdJr5dKsADsnM@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=daniel@makrotopia.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 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.