lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071026115727.GR27248@parisc-linux.org>
Date:	Fri, 26 Oct 2007 05:57:27 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Linus Torvalds <torvalds@...l.org>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org,
	Matthew Wilcox <willy@...ux.intel.com>
Subject: Re: [PATCH 1/4] stringbuf: A string buffer implementation

On Fri, Oct 26, 2007 at 12:11:01PM +1000, Rusty Russell wrote:
> 	This just seems like more optimization and complexity that we need.  Interfaces
> using vsnprintf don't seem like good candidates for optimization.

That's a fair point, but I'm optimising for fewer trips into the
slab(/slub/slob) allocator, and thus having less of an impact on the
rest of the system.  Given that 'an alloc on every call' was one of the
complaints Matt had about my v1 stringbuf patch, I can't imagine he'll
be happy about this one either.

> How about this?  It's as simple as I could make it...

Some very cute tricks in there; I particularly like passing a
double-pointer to ...printf so that the caller doesn't have to check
the return value.

Ultimately, I don't particularly care what version of stringbuf gets
merged, I just want something to make my dmesg non-ugly.  The fact that
my stringbuf implementation looked so damn similar to half a dozen things
that people had already invented elsewhere in the kernel made me think
that this was a good interface because it could be used to replace their
complex code too.

If you want to see some really complex stringbuffer-esque code that needs
replacing, take a look at pnp_info_buffer in drivers/pnp/interface.c ...

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ