Prev: core_pattern pipe documentation - draft 2
Next: mm/cgroup.c add error check
From: Peter Oberparleiter on 6 May 2008 14:40
Andrew Morton wrote:
> On Mon, 05 May 2008 17:24:37 +0200 Peter Oberparleiter <peter.oberparleiter(a)de.ibm.com> wrote:
>
>> From: Peter Oberparleiter <peter.oberparleiter(a)de.ibm.com>
>> Index: linux-2.6.26-rc1/fs/seq_file.c
>> ===================================================================
>> --- linux-2.6.26-rc1.orig/fs/seq_file.c
>> +++ linux-2.6.26-rc1/fs/seq_file.c
>> @@ -554,6 +554,18 @@ int seq_puts(struct seq_file *m, const c
>> }
>> EXPORT_SYMBOL(seq_puts);
>>
>> +int seq_write(struct seq_file *m, const void *s, size_t len)
>
> Most of the other seq_file interface functions are nicely documented.

Documentation will be added with the next resend.

>> +{
>> + if (m->count + len < m->size) {
>
> Are you sure that shouldn't be >=?

If I understood seq_read() correctly, then < is correct:
m->count == m->size seems to be used as special marker for seq_read()
and >= doesn't make sense to me in this place. Also seq_printf() and
seq_puts() follow the same scheme.

>> + memcpy(m->buf + m->count, s, len);
>> + m->count += len;
>> + return 0;
>> + }
>> + m->count = m->size;
>> + return -1;
>> +}
>> +EXPORT_SYMBOL(seq_write);
>
> Usually when a write-style function is passed too much data it will write
> as much as it can and will then return a smaller-than-requested value.

A write function in the context of the seq_file interface seems to be
defined more as an all-or-nothing business: user wants to read, buffer
is half-full, write is called, item doesn't fit, buffer is emptied,
write is called again, buffer doesn't fit, buffer size is doubled,
write is called again, etc.

> That's inappropriate for your application of seq_write(), but perhaps is
> appropriate for other future callers?

seq_write() is almost identical to the already existing seq_puts() which
led me to believe that it would fit the overall logic.

> This function has an upper limit of PAGE_SIZE bytes, I think? The covering
> documentation should explain such things.

seq_read() will double its internal buffer size if an item doesn't fit.


Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 6 May 2008 00:40
On Mon, 05 May 2008 17:24:37 +0200 Peter Oberparleiter <peter.oberparleiter(a)de.ibm.com> wrote:

> From: Peter Oberparleiter <peter.oberparleiter(a)de.ibm.com>
>
> seq_write() can be used to construct seq_files containing arbitrary
> data. Required by the gcov-profiling interface to synthesize binary
> profiling data files.
>
> Signed-off-by: Peter Oberparleiter <peter.oberparleiter(a)de.ibm.com>
> ---
> fs/seq_file.c | 12 ++++++++++++
> include/linux/seq_file.h | 1 +
> 2 files changed, 13 insertions(+)
>
> Index: linux-2.6.26-rc1/fs/seq_file.c
> ===================================================================
> --- linux-2.6.26-rc1.orig/fs/seq_file.c
> +++ linux-2.6.26-rc1/fs/seq_file.c
> @@ -554,6 +554,18 @@ int seq_puts(struct seq_file *m, const c
> }
> EXPORT_SYMBOL(seq_puts);
>
> +int seq_write(struct seq_file *m, const void *s, size_t len)

Most of the other seq_file interface functions are nicely documented.

> +{
> + if (m->count + len < m->size) {

Are you sure that shouldn't be >=?

> + memcpy(m->buf + m->count, s, len);
> + m->count += len;
> + return 0;
> + }
> + m->count = m->size;
> + return -1;
> +}
> +EXPORT_SYMBOL(seq_write);

Usually when a write-style function is passed too much data it will write
as much as it can and will then return a smaller-than-requested value.

That's inappropriate for your application of seq_write(), but perhaps is
appropriate for other future callers?

This function has an upper limit of PAGE_SIZE bytes, I think? The covering
documentation should explain such things.

> struct list_head *seq_list_start(struct list_head *head, loff_t pos)
> {
> struct list_head *lh;
> Index: linux-2.6.26-rc1/include/linux/seq_file.h
> ===================================================================
> --- linux-2.6.26-rc1.orig/include/linux/seq_file.h
> +++ linux-2.6.26-rc1/include/linux/seq_file.h
> @@ -39,6 +39,7 @@ int seq_release(struct inode *, struct f
> int seq_escape(struct seq_file *, const char *, const char *);
> int seq_putc(struct seq_file *m, char c);
> int seq_puts(struct seq_file *m, const char *s);
> +int seq_write(struct seq_file *m, const void *s, size_t len);
>
> int seq_printf(struct seq_file *, const char *, ...)
> __attribute__ ((format (printf,2,3)));
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alexey Dobriyan on 7 May 2008 15:30
On Mon, May 05, 2008 at 09:36:44PM -0700, Andrew Morton wrote:
> On Mon, 05 May 2008 17:24:37 +0200 Peter Oberparleiter <peter.oberparleiter(a)de.ibm.com> wrote:
> > --- linux-2.6.26-rc1.orig/fs/seq_file.c
> > +++ linux-2.6.26-rc1/fs/seq_file.c

> > +int seq_write(struct seq_file *m, const void *s, size_t len)

> > +{
> > + if (m->count + len < m->size) {
>
> Are you sure that shouldn't be >=?

No!

->count is how much bytes are already in buffer.
len is len.
->size is end of page(s).

>
> > + memcpy(m->buf + m->count, s, len);
> > + m->count += len;
> > + return 0;
> > + }
> > + m->count = m->size;
> > + return -1;
> > +}
> > +EXPORT_SYMBOL(seq_write);

I'd call function seq_memcpy() though.

> This function has an upper limit of PAGE_SIZE bytes, I think? The covering
> documentation should explain such things.

Again, no.

At first buffer is PAGE_SIZE. If output is bigger, ->count is dubbed to
->size, so when ->show() returns, size of buffer is doubled until it
fits in. See "while(1)" loop in seq_read().

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: core_pattern pipe documentation - draft 2
Next: mm/cgroup.c add error check