Hello, Joe. On Thu, Sep 10, 2015 at 08:41:25AM -0700, Joe Perches wrote: > 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.
Yeah, but the caller still should be able to call, say, scnprintf() with a limited buffer and get the output till the end of the buffer along with the indication that the output has been truncated. > %*pb isn't capable of multiple line output and > seq_printf output would also fail as it uses k.alloc > memory not vmalloc. Heh, and it should fail. > 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. I'm not that worried about the berserk cases which try to print a really long output on consoles but the subtle failure modes are worrying. > > 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. That's 256Mbytes of bitmap. I don't think we need to worry about that at the moment. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
