All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Christoph Hellwig <hch@infradead.org>,
	Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	Jan Kara <jack@suse.cz>, "Darrick J . Wong" <djwong@kernel.org>,
	Ojaswin Mujoo <ojaswin@linux.ibm.com>
Subject: Re: [RFCv2 2/8] libfs: Add __generic_file_fsync_nolock implementation
Date: Wed, 12 Apr 2023 19:32:26 +0530	[thread overview]
Message-ID: <87ttxlyz9p.fsf@doe.com> (raw)
In-Reply-To: <ZDaZR+zHcpUyNOND@infradead.org>

Christoph Hellwig <hch@infradead.org> writes:

> On Tue, Apr 11, 2023 at 01:33:17PM +0100, Matthew Wilcox wrote:
>> On Mon, Apr 10, 2023 at 10:27:10PM -0700, Christoph Hellwig wrote:
>> > On Tue, Apr 11, 2023 at 10:51:50AM +0530, Ritesh Harjani (IBM) wrote:
>> > > +/**
>> > > + * __generic_file_fsync_nolock - generic fsync implementation for simple
>> > > + * filesystems with no inode lock
>> >
>> > No reallz need for the __ prefix in the name.
>>
>> It kind of makes sense though.
>>
>> generic_file_fsync does the flush
>> __generic_file_fsync doesn't do the flush
>> __generic_file_fsync_nolock doesn't do the flush and doesn't lock/unlock
>
> Indeed.  Part of it is that the naming is a bit horrible.
> Maybe it should move to buffer.c and be called generic_buffer_fsync,
> or generic_block_fsync which still wouldn't be perfect but match the
> buffer.c naming scheme.
>

Eventually it anyways needs some work to see if we can kill the lock
variant all together. I didn't do that in this series which is
focused on ext2 conversion of iomap.
So, if it's not that bad, I would like to keep both function
definitions at one place so that it can be worked out later.

>>
>> > > +extern int __generic_file_fsync_nolock(struct file *, loff_t, loff_t, int);
>> >
>> > No need for the extern.  And at least I personally prefer to spell out
>> > the parameter names to make the prototype much more readable.
>>
>> Agreed, although I make an exception for the 'struct file *'.  Naming that
>> parameter adds no value, but a plain int is just obscene.
>>
>> int __generic_file_fsync_nolock(struct file *, loff_t start, loff_t end,
>> 		bool datasync);
>
> While I agree that it's not needed for the file, leaving it out is a bit
> silly.
>

Sure. Will fix it.

>> (yes, the other variants don't use a bool for datasync, but they should)
>
> .. including the ->fsync prototype to make it work ..

Sure, this work should go as a seperate series.

-ritesh

  reply	other threads:[~2023-04-12 14:02 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-11  5:21 [RFCv2 0/8] ext2: DIO to use iomap Ritesh Harjani (IBM)
2023-04-11  5:21 ` [RFCv2 1/8] ext2/dax: Fix ext2_setsize when len is page aligned Ritesh Harjani (IBM)
2023-04-11 14:29   ` Darrick J. Wong
2023-04-11  5:21 ` [RFCv2 2/8] libfs: Add __generic_file_fsync_nolock implementation Ritesh Harjani (IBM)
2023-04-11  5:27   ` Christoph Hellwig
2023-04-11 12:33     ` Matthew Wilcox
2023-04-11 15:12       ` Ritesh Harjani
2023-04-12 11:43       ` Christoph Hellwig
2023-04-12 14:02         ` Ritesh Harjani [this message]
2023-04-13  9:51         ` Christian Brauner
2023-04-11  5:21 ` [RFCv2 3/8] ext4: Use " Ritesh Harjani (IBM)
2023-04-11  5:21 ` [RFCv2 4/8] ext2: " Ritesh Harjani (IBM)
2023-04-11  5:21 ` [RFCv2 5/8] ext2: Move direct-io to use iomap Ritesh Harjani (IBM)
2023-04-11  5:46   ` Christoph Hellwig
2023-04-11 15:21     ` Ritesh Harjani
2023-04-12 11:43       ` Christoph Hellwig
2023-04-12 14:03         ` Ritesh Harjani
2023-04-11  5:21 ` [RFCv2 6/8] iomap: Remove IOMAP_DIO_NOSYNC unused dio flag Ritesh Harjani (IBM)
2023-04-11  5:27   ` Christoph Hellwig
2023-04-11  5:21 ` [RFCv2 7/8] fs.h: Add IOCB_STRINGS for use in trace points Ritesh Harjani (IBM)
2023-04-11  5:38   ` Christoph Hellwig
2023-04-11  5:21 ` [RFCv2 8/8] ext2: Add direct-io " Ritesh Harjani (IBM)
2023-04-11  5:38   ` Christoph Hellwig
2023-04-11 14:34     ` Darrick J. Wong
2023-04-11 15:11       ` Ritesh Harjani
2023-04-12 11:44         ` Christoph Hellwig
2023-04-12 14:07           ` Ritesh Harjani
2023-04-11  8:59   ` kernel test robot
2023-04-11 12:23   ` kernel test robot
2023-04-11 12:44   ` kernel test robot
2023-04-11 13:15   ` kernel test robot
2023-04-12 11:45 ` [RFCv2 0/8] ext2: DIO to use iomap Jan Kara
2023-04-12 14:10   ` Ritesh Harjani

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=87ttxlyz9p.fsf@doe.com \
    --to=ritesh.list@gmail.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=willy@infradead.org \
    /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.