PATCH: seq_file interface to provide large data chunks

seq_file interface, as it exist in last official kernel, never provides more then one page for each 'read' call. Old read_proc_t did loop to fill more than one page.

Following patch against 2.4.21 fixes seq_file to provide more than one page if user requests it.
Many programs do read(large_buffer) once, instead of looping while read()>0. They work wrong with seq_file. Also, one may expect read() to provide whole information atomically (OK, relatively to other process context stuff). This patch loops over while some space remains in user provided buffer.

I am not subscribed to lkml, thus please cc: me (Vladimir Kondratiev <[email protected]>) explicitly.

@@ -55,6 +55,7 @@
        return -EPIPE;
 
    down(&m->sem);
+Again:
    /* grab buffer if we didn't have one */
    if (!m->buf) {
        m->buf = kmalloc(m->size = PAGE_SIZE, GFP_KERNEL);

@@ -123,11 +124,14 @@
        goto Efault;
    copied += n;
    m->count -= n;
+    size -= n;
+    buf += n;
    if (m->count)
        m->from = n;
    else
        pos++;
    m->index = pos;
+    goto Again;

Done:

    if (!copied)
        copied = err;

There is a merge of Al's additional seq_file stuff to 2.4 floating around (its in -ac for one) that may be a better thing to merge instead if we want it

Al ?

Alan,
I analyzed 2 latest patches from www.kernel.org:
patch-2.4.22-pre4 and patch-2.4.22-pre3-ac1.

-pre4 do not touch seq_file;

-pre3-ac1 corrects spelling and adds single_xxx functions. There is no conflict between this patch and my one. I verified, they do apply in any order (with some offset).

Vladimir.

This patch looks rather tab damaged.

I think it's problematic in that it can hold the semaphore for an unbounded amount of time.

I'd suggest dropping and acquiring the semaphore each time through the loop, but then you get into a situation where a second process can cause the returned results to no longer be coherent. Since we'd no longer have a way to get single results, this'd be bad.

Matt Mackall : http://www.selenic.com : of or relating to the moon

Couple of weeks ago I submitted (for 2.4 series) the patch for seq_file that fixes read() behavior to be able return more than one page of data. There was quick mail exchange with Alan, he pointed out that there is some more seq_file stuff (for "single", by the way). Since that - no any information, whether this seq_file stuff is going to be included or, if not, at least any reason. 2.4.22-pre6 released with no seq_file changes.

Regarding to this, I have more generic question: is it some way to track status of patches? Accepted/rejected, scheduled for xxx version? For 2.5 kernel, Bugzilla provides this feature. What for 2.4?

Vladimir.