On Mon, Sep 1, 2014 at 2:49 PM, Geert Uytterhoeven wrote:
> Hi Andy,
>
> On Mon, Sep 1, 2014 at 1:33 PM, Andy Shevchenko
> wrote:
>>> >> However, to protect against overflows if hex_dump_to_buffer() ever
>>> >> changes,
>>> >> I think it would be better to let hex_dump_to_buffer() indicate if
Hi Andy,
On Mon, Sep 1, 2014 at 1:33 PM, Andy Shevchenko
wrote:
>> >> However, to protect against overflows if hex_dump_to_buffer() ever
>> >> changes,
>> >> I think it would be better to let hex_dump_to_buffer() indicate if the
>> >> passed buffer was to small (it already checks the passed
On Mon, 2014-09-01 at 12:59 +0200, Geert Uytterhoeven wrote:
> Hi Andy,
>
> On Mon, Sep 1, 2014 at 12:15 PM, Andy Shevchenko
> wrote:
> I think it needs a call to seq_set_overflow() in case the buffer is too
> small,
> so the caller will retry with a bigger buffer.
> >>>
> >>>
Hi Andy,
On Mon, Sep 1, 2014 at 12:15 PM, Andy Shevchenko
wrote:
I think it needs a call to seq_set_overflow() in case the buffer is too
small,
so the caller will retry with a bigger buffer.
>>>
>>> Yes, in two places it would be useful to do.
>>
>> Two places? I see only one,
On Mon, Sep 1, 2014 at 12:25 PM, Geert Uytterhoeven
wrote:
> Hi Andy,
>
> On Mon, Sep 1, 2014 at 11:09 AM, Andy Shevchenko
> wrote:
>> On Mon, 2014-09-01 at 10:58 +0200, Geert Uytterhoeven wrote:
>>> On Mon, Sep 1, 2014 at 10:36 AM, Andy Shevchenko
>>> wrote:
>>> >> ... and extra copying for no
Hi Andy,
On Mon, Sep 1, 2014 at 11:09 AM, Andy Shevchenko
wrote:
> On Mon, 2014-09-01 at 10:58 +0200, Geert Uytterhoeven wrote:
>> On Mon, Sep 1, 2014 at 10:36 AM, Andy Shevchenko
>> wrote:
>> >> ... and extra copying for no good reason. Why not check that we have
>> >> enough space in buffer
On Mon, 2014-09-01 at 10:58 +0200, Geert Uytterhoeven wrote:
> Hi Andy,
>
> On Mon, Sep 1, 2014 at 10:36 AM, Andy Shevchenko
> wrote:
> >> ... and extra copying for no good reason. Why not check that we have
> >> enough space in buffer and generate directly into it? See what e.g.
> >>
Hi Andy,
On Mon, Sep 1, 2014 at 10:36 AM, Andy Shevchenko
wrote:
>> ... and extra copying for no good reason. Why not check that we have
>> enough space in buffer and generate directly into it? See what e.g.
>> seq_escape() is doing...
>
> What about this variant?
I think it needs a call to
On Sat, 2014-08-30 at 23:54 +0100, Al Viro wrote:
> On Mon, Aug 25, 2014 at 12:03:11PM +0300, Andy Shevchenko wrote:
> > The new seq_hex_dump() is a complete analogue of print_hex_dump().
> >
> > We have few users of this functionality already. It allows to reduce their
> > codebase.
>
> I
On Sat, 2014-08-30 at 23:54 +0100, Al Viro wrote:
On Mon, Aug 25, 2014 at 12:03:11PM +0300, Andy Shevchenko wrote:
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
I really don't
Hi Andy,
On Mon, Sep 1, 2014 at 10:36 AM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
... and extra copying for no good reason. Why not check that we have
enough space in buffer and generate directly into it? See what e.g.
seq_escape() is doing...
What about this variant?
I
On Mon, 2014-09-01 at 10:58 +0200, Geert Uytterhoeven wrote:
Hi Andy,
On Mon, Sep 1, 2014 at 10:36 AM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
... and extra copying for no good reason. Why not check that we have
enough space in buffer and generate directly into it? See
Hi Andy,
On Mon, Sep 1, 2014 at 11:09 AM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
On Mon, 2014-09-01 at 10:58 +0200, Geert Uytterhoeven wrote:
On Mon, Sep 1, 2014 at 10:36 AM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
... and extra copying for no good reason.
On Mon, Sep 1, 2014 at 12:25 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
Hi Andy,
On Mon, Sep 1, 2014 at 11:09 AM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
On Mon, 2014-09-01 at 10:58 +0200, Geert Uytterhoeven wrote:
On Mon, Sep 1, 2014 at 10:36 AM, Andy Shevchenko
Hi Andy,
On Mon, Sep 1, 2014 at 12:15 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
I think it needs a call to seq_set_overflow() in case the buffer is too
small,
so the caller will retry with a bigger buffer.
Yes, in two places it would be useful to do.
Two places? I see only one,
On Mon, 2014-09-01 at 12:59 +0200, Geert Uytterhoeven wrote:
Hi Andy,
On Mon, Sep 1, 2014 at 12:15 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
I think it needs a call to seq_set_overflow() in case the buffer is too
small,
so the caller will retry with a bigger buffer.
Yes,
Hi Andy,
On Mon, Sep 1, 2014 at 1:33 PM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
However, to protect against overflows if hex_dump_to_buffer() ever
changes,
I think it would be better to let hex_dump_to_buffer() indicate if the
passed buffer was to small (it already
On Mon, Sep 1, 2014 at 2:49 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote:
Hi Andy,
On Mon, Sep 1, 2014 at 1:33 PM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
However, to protect against overflows if hex_dump_to_buffer() ever
changes,
I think it would be better to let
On Mon, Aug 25, 2014 at 12:03:11PM +0300, Andy Shevchenko wrote:
> The new seq_hex_dump() is a complete analogue of print_hex_dump().
>
> We have few users of this functionality already. It allows to reduce their
> codebase.
I really don't like the stack footprint.
> + unsigned char
On Mon, Aug 25, 2014 at 12:03:11PM +0300, Andy Shevchenko wrote:
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
I really don't like the stack footprint.
+ unsigned char linebuf[32 *
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
Signed-off-by: Andy Shevchenko
---
fs/seq_file.c| 35 +++
include/linux/seq_file.h | 4
2
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
fs/seq_file.c| 35 +++
22 matches
Mail list logo
