Thread (20 messages) 20 messages, 6 authors, 2023-07-31

Re: [PATCH 01/32] block: Provide blkdev_get_handle_* functions

From: Jan Kara <jack@suse.cz>
Date: 2023-07-04 13:04:40
Also in: dm-devel, linux-bcache, linux-block, linux-btrfs, linux-ext4, linux-f2fs-devel, linux-fsdevel, linux-mm, linux-nfs, linux-nvme, linux-pm, linux-s390, linux-scsi, linux-xfs, target-devel, xen-devel

On Tue 04-07-23 13:43:51, Matthew Wilcox wrote:
On Tue, Jul 04, 2023 at 02:21:28PM +0200, Jan Kara wrote:
quoted
+struct bdev_handle *blkdev_get_handle_by_dev(dev_t dev, blk_mode_t mode,
+		void *holder, const struct blk_holder_ops *hops)
+{
+	struct bdev_handle *handle = kmalloc(sizeof(struct bdev_handle),
+					     GFP_KERNEL);
+	struct block_device *bdev;
+
+	if (!handle)
+		return ERR_PTR(-ENOMEM);
+	bdev = blkdev_get_by_dev(dev, mode, holder, hops);
+	if (IS_ERR(bdev))
+		return ERR_CAST(bdev);
Would we be better off with a handle->error (and a NULL return from this
function means "we couldn't allocate a handle")?  I have no objection
to what you've done here, just wondering if it might end up nicer for
the users.
Hum, I've checked a couple of users and it seems it would be more
complicated for the users to handle this convention than the one I've
chosen. And that one is also pretty standard so I think by the principle of
least surprise it is also better.

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help