From: Joe Perches <joe@perches.com>
To: Tejun Heo <tj@kernel.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Maurizio Lombardi <mlombard@redhat.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lib/vsprintf.c: increase the size of the field_width variable
Date: Thu, 10 Sep 2015 08:41:25 -0700 [thread overview]
Message-ID: <1441899685.17219.158.camel@perches.com> (raw)
In-Reply-To: <20150910143629.GB8114@mtj.duckdns.org>
On Thu, 2015-09-10 at 10:36 -0400, Tejun Heo wrote:
> On Wed, Sep 09, 2015 at 12:26:39PM -0700, Joe Perches wrote:
> > > > %*pb is meant for smallish bitmaps, not big ones.
[]
> The use case isn't from me, but why not?
Imagine the output of the 500k bitmap if every other
bit is set.
%*pb isn't capable of multiple line output and
seq_printf output would also fail as it uses k.alloc
memory not vmalloc.
I think that a more limited mechanism might be to use a
multiple line oriented function like print_hex_debug
and not try to emit the entire thing in a single go.
> Why are we even copying the struct on invocations?
> Only some functions modify the values after all.
> We might as well pass around pointer to the struct
> and let the callees wihch modify them copy the
> fields in local vars like normal functions.
You are of course welcome and able to change it.
btw: the current implementation has a limitation
on 32 bit arches as it uses an int argument for the
unsigned long count of bits in a bitmap.
That's a bitmap that should not be printed anyway.
next prev parent reply other threads:[~2015-09-10 15:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 10:13 [PATCH] lib/vsprintf.c: increase the size of the field_width variable Maurizio Lombardi
2015-09-09 13:39 ` Tejun Heo
2015-09-09 16:33 ` Joe Perches
2015-09-09 16:36 ` Tejun Heo
2015-09-09 16:55 ` Joe Perches
2015-09-09 18:51 ` Rasmus Villemoes
2015-09-09 19:26 ` Joe Perches
2015-09-10 14:36 ` Tejun Heo
2015-09-10 15:41 ` Joe Perches [this message]
2015-09-10 15:47 ` Tejun Heo
2015-09-10 7:04 ` Maurizio Lombardi
2015-09-10 7:13 ` Maurizio Lombardi
2015-09-10 7:38 ` Joe Perches
2015-09-10 7:56 ` Rasmus Villemoes
2015-09-10 8:17 ` Joe Perches
2015-09-10 14:43 ` Tejun Heo
2015-09-10 8:39 ` Maurizio Lombardi
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=1441899685.17219.158.camel@perches.com \
--to=joe@perches.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mlombard@redhat.com \
--cc=tj@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.