From: David Sterba <dsterba@suse.cz>
To: Nikolay Borisov <nborisov@suse.com>
Cc: David Sterba <dsterba@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 6/6] btrfs: lift bio_set_dev from bio allocation helpers
Date: Wed, 19 Jun 2019 14:03:14 +0200 [thread overview]
Message-ID: <20190619120314.GC8917@twin.jikos.cz> (raw)
In-Reply-To: <d36987c6-2e18-5b2e-0760-0cf151446586@suse.com>
On Wed, Jun 19, 2019 at 10:02:53AM +0300, Nikolay Borisov wrote:
>
>
> On 18.06.19 г. 21:00 ч., David Sterba wrote:
> > The block device is passed around for the only purpose to set it in new
> > bios. Move the assignment one level up. This is a preparatory patch for
> > further bdev cleanups.
> >
> > Signed-off-by: David Sterba <dsterba@suse.com>
>
> Reviewed-by: Nikolay Borisov <nborisov@suse.com>
>
> Albeit I'd go as far as suggesting to make btrfs_bio_alloc a void
> function similar to the generic bio alloc functions. It should be up to
> the callers of bio alloc functions to initialize the bio in one place.
> Even after your patch initialization is split across btrfs_bio_alloc and
> its caller which seems a bit idiosyncratic.
The bio_set_dev will go away (device for a bio is set right before it's
submitted), so there will be only the allocation and the code as before.
Some kind of split is probably inevitable, btrfs_bio_alloc needs the
bioset that's private to extent_io.c and the callers know what to set to
bi_opf etc. Maybe, as I'm looking at it now, btrfs_bio_alloc can take
the value for opf, private and end_io as argument. All the callsites
fill these three. That would make it consistent.
prev parent reply other threads:[~2019-06-19 12:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 18:00 [PATCH 0/6] Minor cleanups David Sterba
2019-06-18 18:00 ` [PATCH 1/6] btrfs: use common helpers for eb leak messages David Sterba
2019-06-18 18:00 ` [PATCH 2/6] btrfs: use common helpers for extent IO state insertion messages David Sterba
2019-06-19 6:54 ` Nikolay Borisov
2019-06-19 11:50 ` David Sterba
2019-06-18 18:00 ` [PATCH 3/6] btrfs: drop default value assignments in enums David Sterba
2019-06-18 18:00 ` [PATCH 4/6] btrfs: use raid_attr to adjust minimal stripe size in btrfs_calc_avail_data_space David Sterba
2019-06-19 6:57 ` Nikolay Borisov
2019-06-18 18:00 ` [PATCH 5/6] btrfs: use raid_attr for minimum stripe count " David Sterba
2019-06-19 7:51 ` Nikolay Borisov
2019-06-19 12:09 ` David Sterba
2019-06-18 18:00 ` [PATCH 6/6] btrfs: lift bio_set_dev from bio allocation helpers David Sterba
2019-06-19 7:02 ` Nikolay Borisov
2019-06-19 12:03 ` David Sterba [this message]
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=20190619120314.GC8917@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.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.