From: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: ltp-list@lists.sourceforge.net,
ltp-coverage@lists.sourceforge.net, linux-kernel@vger.kernel.org,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC PATCH 4/6] seq_file: add function to write binary data
Date: Tue, 06 May 2008 20:37:04 +0200 [thread overview]
Message-ID: <4820A550.8090500@de.ibm.com> (raw)
In-Reply-To: <20080505213644.b153ee68.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Mon, 05 May 2008 17:24:37 +0200 Peter Oberparleiter <peter.oberparleiter@de.ibm.com> wrote:
>
>> From: Peter Oberparleiter <peter.oberparleiter@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
next prev parent reply other threads:[~2008-05-06 18:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 15:24 [RFC PATCH 4/6] seq_file: add function to write binary data Peter Oberparleiter
2008-05-06 4:36 ` Andrew Morton
2008-05-06 18:37 ` Peter Oberparleiter [this message]
2008-05-07 20:17 ` Alexey Dobriyan
2008-05-07 20:45 ` Alexey Dobriyan
2008-05-08 7:42 ` Peter Oberparleiter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4820A550.8090500@de.ibm.com \
--to=peter.oberparleiter@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltp-coverage@lists.sourceforge.net \
--cc=ltp-list@lists.sourceforge.net \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.