Re: [PATCH] Reduce stack used by lib/hexdump.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Dec 05, 2007, at 21:42:35, Joe Perches wrote:
On Wed, 2007-12-05 at 18:18 -0800, Randy Dunlap wrote:
Joe Perches wrote:
Maybe just eliminate the 16 or 32 byte width option and force it to only 16 byte widths.
Have you checked users (callers)? I'm pretty sure that one of the callers wanted 32 and that's why it's there.

I did.  There is only 1 subsystem.  That's easy to change.

drivers/mtd/ubi/debug.c: print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_OFFSET, 32, 1, drivers/mtd/ubi/io.c: print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_OFFSET, 32, 1,

Long lines in the log file are not too easy to read anyway. Using 16 byte dumps per line instead of 32 isn't painful.

It gets rid of the allocation, reduces the argument count and makes the kernel smaller. I think it's all good.

Every current caller would have to change though.

Alternatively, since print_hex_dump is not a performance-critical path (and usually indicates an error/debug condition), you could probably just make a static "hexdump_lock" spinlock and spin_lock_irqsave()/spin_unlock_irqrestore(). It would always nest inside any other lock (except during crash, where we break locks already for printk()), and I doubt any of the callers would notice the serialization since they're already serialized on the printk buffer.

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[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]
  Powered by Linux