All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: fdmanana@kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/3] btrfs: return -EAGAIN for NOWAIT dio reads/writes on compressed and inline extents
Date: Thu, 7 Jul 2022 18:47:36 +0200	[thread overview]
Message-ID: <20220707164736.GH15169@twin.jikos.cz> (raw)
In-Reply-To: <YsLVtZ+SpKOfiD5Z@infradead.org>

On Mon, Jul 04, 2022 at 04:57:41AM -0700, Christoph Hellwig wrote:
> On Mon, Jul 04, 2022 at 12:42:03PM +0100, fdmanana@kernel.org wrote:
> > +		 * filemap_read(), we fail to fault in pages for the read buffer,
> > +		 * in which case filemap_read() returns a short read (the number
> > +		 * of bytes previously read is > 0, so it does not return -EFAULT).
> 
> Two overly long lines here, which are especially annoying in block
> comments as they completely break the layout.

The only line that is not under 81 is the last one and what does not if
is "T).". This is within the acceptable overflow and I adjust many lines
in patches based on how the code looks (ie. avoiding some line breaks)
and if the potentially overflown text does not obscure the meaning.

Keeping the lines under 80 makes sense for me personally when resolving
conflicts in the 3+1 vimdiff view, but the limit is not strict and the
criteria is if the code follows the common patterns we've settled on and
what people in the btrfs group are used to, either reading or writing.
The kernel coding style does not cover everything and is a good starting
point. The rest is at
https://btrfs.wiki.kernel.org/index.php/Development_notes#Coding_style_preferences

  reply	other threads:[~2022-07-07 16:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-04 11:42 [PATCH 0/3] btrfs: a few direct IO fixes/improvements fdmanana
2022-07-04 11:42 ` [PATCH 1/3] btrfs: return -EAGAIN for NOWAIT dio reads/writes on compressed and inline extents fdmanana
2022-07-04 11:57   ` Christoph Hellwig
2022-07-07 16:47     ` David Sterba [this message]
2022-07-04 11:42 ` [PATCH 2/3] btrfs: don't fallback to buffered IO for NOWAIT direct IO writes fdmanana
2022-07-04 12:00   ` Christoph Hellwig
2022-07-04 12:11     ` Filipe Manana
2022-07-04 12:12       ` Christoph Hellwig
2022-07-04 12:19         ` Filipe Manana
2022-07-04 12:37           ` Christoph Hellwig
2022-07-04 11:42 ` [PATCH 3/3] btrfs: fault in pages for dio reads/writes in a more controlled way fdmanana
2022-07-08 15:20 ` [PATCH 0/3] btrfs: a few direct IO fixes/improvements David Sterba

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=20220707164736.GH15169@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=fdmanana@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-btrfs@vger.kernel.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.