From: "Holger Hoffstätte" <holger@applied-asynchrony.com>
To: Adam Borowski <kilobyte@angband.pl>,
David Sterba <dsterba@suse.cz>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] btrfs: make block group flags in balance printks human-readable
Date: Tue, 8 Nov 2016 14:42:12 +0100 [thread overview]
Message-ID: <5821D634.4070204@applied-asynchrony.com> (raw)
In-Reply-To: <20161107214049.4378-1-kilobyte@angband.pl>
On 11/07/16 22:40, Adam Borowski wrote:
> They're not even documented anywhere, letting users with no recourse but
> to RTFS. It's no big burden to output the bitfield as words.
>
> Also, display unknown flags as hex.
>
> Signed-off-by: Adam Borowski <kilobyte@angband.pl>
[..]
>
> /*
> + * explain bit flags, prefixed by a '|' that'll be dropped
> + */
> +static char *describe_block_group_flags(char *buf, u64 flags)
> +{
> +#define BUF_SIZE 128
> + char *buf0 = buf = kmalloc(BUF_SIZE, GFP_NOFS);
[..]
Maybe I'm missing some clever (?) trick here, but what's the point of passing
in a potentially uninitialized 'buf' when it's immediately reassigned locally,
and a new value is returned and assigned at the call site?
IMHO you'd probably either want to pass the buffer in or return it, but not
both - and in that case the allocation should probably be hoisted out
into the caller as well, if only to make things a bit more symmetric.
-h
next prev parent reply other threads:[~2016-11-08 13:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 7:26 [PATCH] btrfs: make block group flags in balance printks human-readable Adam Borowski
2016-11-07 14:11 ` Holger Hoffstätte
2016-11-07 16:58 ` David Sterba
2016-11-07 21:38 ` Adam Borowski
2016-11-07 21:40 ` [PATCH v2] " Adam Borowski
2016-11-08 13:42 ` Holger Hoffstätte [this message]
2016-11-11 23:59 ` [PATCH v3-onstack] " Adam Borowski
2016-11-14 16:37 ` David Sterba
2016-11-14 17:44 ` [PATCH v4] " Adam Borowski
2016-11-14 18:24 ` 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=5821D634.4070204@applied-asynchrony.com \
--to=holger@applied-asynchrony.com \
--cc=dsterba@suse.cz \
--cc=kilobyte@angband.pl \
--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.