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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
