From: Ming Lei <ming.lei@redhat.com> To: Christoph Hellwig <hch@infradead.org> Cc: Jens Axboe <axboe@fb.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Kent Overstreet <kent.overstreet@gmail.com>, David Sterba <dsterba@suse.cz>, Huang Ying <ying.huang@intel.com>, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Theodore Ts'o <tytso@mit.edu>, "Darrick J . Wong" <darrick.wong@oracle.com>, Coly Li <colyli@suse.de>, Filipe Manana <fdmanana@gmail.com>, Randy Dunlap <rdunlap@infradead.org> Subject: Re: [PATCH V6 00/30] block: support multipage bvec Date: Tue, 12 Jun 2018 11:42:49 +0800 [thread overview] Message-ID: <20180612034242.GC26412@ming.t460p> (raw) In-Reply-To: <20180611164806.GA7452@infradead.org> On Mon, Jun 11, 2018 at 09:48:06AM -0700, Christoph Hellwig wrote: > І think the new naming scheme in this series is a nightmare. It > confuses the heck out of me, and that is despite knowing many bits of > the block layer inside out, and reviewing previous series. In V5, there isn't such issue, since bio_for_each_segment* is renamed into bio_for_each_page* first before doing the change. > > I think we need to take a step back and figure out what names what we > want in the end, and how we get there separately. Right, I agree, last year I told people that naming may be the biggest issue for this patchset. > > For the end result using bio_for_each_page in some form for the per-page > iteration seems like the only sensible idea, as that is what it does. Yeah, I agree, but except for renaming bio_for_each_segment* into bio_for_each_page* or whatever first, I don't see any way to deal with it cleanly. Seems Jens isn't fine with the big renaming, then I follow the suggestion of taking 'chunk' for representing multipage bvec in V6. > > For the bio-vec iteration I'm fine with either bio_for_each_bvec as that > exactly explains what it does, or bio_for_each_segment to keep the > change at a minimum. If bio_for_each_segment() is fine, that is basically what this patch is doing, then could you share me what the actual naming issue is in V6? And basically the name of 'chunk' is introduced for multipage bvec. > > And in terms of how to get there: maybe we need to move all the drivers > and file systems to the new names first before the actual changes to > document all the intent. That is exactly what I have done in V5, but that way is refused. Guys, so what can we do to make progress for this naming issue? Thanks, Ming
WARNING: multiple messages have this Message-ID (diff)
From: Ming Lei <ming.lei@redhat.com> To: Christoph Hellwig <hch@infradead.org> Cc: Jens Axboe <axboe@fb.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Kent Overstreet <kent.overstreet@gmail.com>, David Sterba <dsterba@suse.cz>, Huang Ying <ying.huang@intel.com>, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Theodore Ts'o <tytso@mit.edu>, "Darrick J . Wong" <darrick.wong@oracle.com>, Coly Li <colyli@suse.de>, Filipe Manana <fdmanana@gmail.com>, Randy Dunlap <rdunlap@infradead.org> Subject: Re: [PATCH V6 00/30] block: support multipage bvec Date: Tue, 12 Jun 2018 11:42:49 +0800 [thread overview] Message-ID: <20180612034242.GC26412@ming.t460p> (raw) In-Reply-To: <20180611164806.GA7452@infradead.org> On Mon, Jun 11, 2018 at 09:48:06AM -0700, Christoph Hellwig wrote: > D? think the new naming scheme in this series is a nightmare. It > confuses the heck out of me, and that is despite knowing many bits of > the block layer inside out, and reviewing previous series. In V5, there isn't such issue, since bio_for_each_segment* is renamed into bio_for_each_page* first before doing the change. > > I think we need to take a step back and figure out what names what we > want in the end, and how we get there separately. Right, I agree, last year I told people that naming may be the biggest issue for this patchset. > > For the end result using bio_for_each_page in some form for the per-page > iteration seems like the only sensible idea, as that is what it does. Yeah, I agree, but except for renaming bio_for_each_segment* into bio_for_each_page* or whatever first, I don't see any way to deal with it cleanly. Seems Jens isn't fine with the big renaming, then I follow the suggestion of taking 'chunk' for representing multipage bvec in V6. > > For the bio-vec iteration I'm fine with either bio_for_each_bvec as that > exactly explains what it does, or bio_for_each_segment to keep the > change at a minimum. If bio_for_each_segment() is fine, that is basically what this patch is doing, then could you share me what the actual naming issue is in V6? And basically the name of 'chunk' is introduced for multipage bvec. > > And in terms of how to get there: maybe we need to move all the drivers > and file systems to the new names first before the actual changes to > document all the intent. That is exactly what I have done in V5, but that way is refused. Guys, so what can we do to make progress for this naming issue? Thanks, Ming
next prev parent reply other threads:[~2018-06-12 3:42 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-09 12:29 [PATCH V6 00/30] block: support multipage bvec Ming Lei 2018-06-09 12:29 ` [PATCH V6 01/30] block: simplify bio_check_pages_dirty Ming Lei 2018-06-09 12:29 ` [PATCH V6 02/30] block: bio_set_pages_dirty can't see NULL bv_page in a valid bio_vec Ming Lei 2018-06-09 12:29 ` [PATCH V6 03/30] block: use bio_add_page in bio_iov_iter_get_pages Ming Lei 2018-06-09 12:29 ` [PATCH V6 04/30] block: introduce multipage page bvec helpers Ming Lei 2018-06-09 12:29 ` [PATCH V6 05/30] block: introduce bio_for_each_chunk() Ming Lei 2018-06-09 12:29 ` [PATCH V6 06/30] block: use bio_for_each_chunk() to compute multipage bvec count Ming Lei 2018-06-09 12:29 ` [PATCH V6 07/30] block: use bio_for_each_chunk() to map sg Ming Lei 2018-06-09 12:29 ` [PATCH V6 08/30] block: introduce chunk_last_segment() Ming Lei 2018-06-11 17:19 ` Christoph Hellwig 2018-06-12 3:24 ` Ming Lei 2018-06-09 12:29 ` [PATCH V6 09/30] fs/buffer.c: use bvec iterator to truncate the bio Ming Lei 2018-06-09 12:29 ` [PATCH V6 10/30] btrfs: use chunk_last_segment to get bio's last page Ming Lei 2018-06-09 12:29 ` [PATCH V6 11/30] block: implement bio_pages_all() via bio_for_each_segment_all() Ming Lei 2018-06-13 14:44 ` Christoph Hellwig 2018-06-14 1:23 ` Ming Lei 2018-06-14 6:20 ` Christoph Hellwig 2018-06-09 12:29 ` [PATCH V6 12/30] block: introduce bio_chunks() Ming Lei 2018-06-13 14:47 ` Christoph Hellwig 2018-06-13 14:57 ` Kent Overstreet 2018-06-09 12:29 ` [PATCH V6 13/30] block: introduce rq_for_each_chunk() Ming Lei 2018-06-13 14:48 ` Christoph Hellwig 2018-06-14 1:52 ` Ming Lei 2018-06-09 12:29 ` [PATCH V6 14/30] block: loop: pass multipage chunks to iov_iter Ming Lei 2018-06-09 12:29 ` [PATCH V6 15/30] block: introduce bio_clone_chunk_bioset() Ming Lei 2018-06-13 14:56 ` Christoph Hellwig 2018-06-14 2:01 ` Ming Lei 2018-06-14 6:39 ` Christoph Hellwig 2018-06-14 7:28 ` Ming Lei 2018-06-09 12:30 ` [PATCH V6 16/30] dm: clone bio via bio_clone_chunk_bioset Ming Lei 2018-06-09 12:30 ` [PATCH V6 17/30] block: introduce bio_for_each_chunk_all and bio_for_each_chunk_segment_all Ming Lei 2018-06-09 12:30 ` [PATCH V6 18/30] block: convert to bio_for_each_chunk_segment_all() Ming Lei 2018-06-09 12:30 ` [PATCH V6 19/30] md/dm/bcache: conver to bio_for_each_chunk_segment_all and bio_for_each_chunk_all Ming Lei 2018-06-10 12:38 ` Coly Li 2018-06-13 14:57 ` Christoph Hellwig 2018-06-09 12:30 ` [PATCH V6 20/30] fs: conver to bio_for_each_chunk_segment_all() Ming Lei 2018-06-09 12:30 ` [PATCH V6 21/30] btrfs: conver to bio_for_each_chunk_segment_all Ming Lei 2018-06-09 12:30 ` [PATCH V6 22/30] ext4: " Ming Lei 2018-06-09 12:30 ` [PATCH V6 23/30] f2fs: " Ming Lei 2018-06-09 12:30 ` [PATCH V6 24/30] xfs: " Ming Lei 2018-06-09 12:30 ` [PATCH V6 25/30] exofs: " Ming Lei 2018-06-09 12:30 ` [PATCH V6 26/30] gfs2: " Ming Lei 2018-06-09 12:30 ` [PATCH V6 27/30] block: kill bio_for_each_segment_all() Ming Lei 2018-06-09 12:30 ` [PATCH V6 28/30] block: enable multipage bvecs Ming Lei 2018-06-09 12:30 ` [PATCH V6 29/30] block: always define BIO_MAX_PAGES as 256 Ming Lei 2018-06-09 12:30 ` [PATCH V6 30/30] block: document usage of bio iterator helpers Ming Lei 2018-06-15 15:43 ` Gi-Oh Kim 2018-06-15 15:43 ` Gi-Oh Kim 2018-06-11 16:48 ` [PATCH V6 00/30] block: support multipage bvec Christoph Hellwig 2018-06-11 16:48 ` Christoph Hellwig 2018-06-12 3:42 ` Ming Lei [this message] 2018-06-12 3:42 ` Ming Lei 2018-06-13 14:42 ` Christoph Hellwig 2018-06-13 14:42 ` Christoph Hellwig 2018-06-14 1:18 ` Ming Lei 2018-06-14 1:18 ` Ming Lei 2018-06-14 6:18 ` Christoph Hellwig 2018-06-13 14:59 ` Kent Overstreet 2018-06-14 1:20 ` Ming Lei 2018-06-15 12:59 ` Gi-Oh Kim 2018-06-15 12:59 ` Gi-Oh Kim 2018-06-21 1:17 ` Ming Lei 2018-06-21 8:40 ` Gi-Oh Kim 2018-06-21 8:40 ` Gi-Oh Kim
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=20180612034242.GC26412@ming.t460p \ --to=ming.lei@redhat.com \ --cc=axboe@fb.com \ --cc=colyli@suse.de \ --cc=darrick.wong@oracle.com \ --cc=dsterba@suse.cz \ --cc=fdmanana@gmail.com \ --cc=hch@infradead.org \ --cc=kent.overstreet@gmail.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=rdunlap@infradead.org \ --cc=tytso@mit.edu \ --cc=viro@zeniv.linux.org.uk \ --cc=ying.huang@intel.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: linkBe 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.