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.
Cheers,
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  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]
  Powered by Linux