On Thu, 2014-07-10 at 09:58 +0200, Marek Vasut wrote:

On Wednesday, July 09, 2014 at 11:21:08 PM, Joe Perches wrote:

quoted

On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:

quoted

The above function looks like almost verbatim copy of print_hex_dump().
The only difference I can spot is that it's calling seq_printf() instead
of printk(). Can you not instead generalize print_hex_dump() and based
on it's invocation, make it call either seq_printf() or printk() ?

How do you propose doing that given any seq_<foo> call
requires a struct seq_file * and print_hex_dump needs
a KERN_<LEVEL>.

I can imagine a rather nasty way, I can't say I would like it myself tho. The 
general idea would be to pull out the entire switch {} statement into a separate 
functions , one for printk() and one for seq_printf() cases. Then, have a 
generic do_hex_dump() call which would take as an argument a pointer to either 
of those functions and a void * to either the seq_file or level . Finally, there 
would have to be a wrapper to call the do_hex_dump() with the correct function 
pointer and it's associated arg.

Nasty? Yes ... Ineffective? Most likely.

It looks not good idea, yeah.

quoted

Is there an actual value to it?

Reducing the code duplication, but I wonder if there is a smarter solution than 
the horrid one above.

I have considered to modify hex_dump_to_buffer() to return how many
bytes it actually proceed to the buffer. In that case we can directly
print to m->buf like other seq_<foo> calls do.

But I still have doubts about it. Any opinion?

-- 
Andy Shevchenko [off-list ref]
Intel Finland Oy