lkml.org 
[lkml]   [2007]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Reduce stack used by lib/hexdump.c
Date
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



\
 
 \ /
  Last update: 2007-12-06 07:48    [W:0.070 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site