sequence files -- what the documentation never made clear

["Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>]

  ok, i've finally figured out what's happening with sequence files in
terms of starting position and what EOF means and so on.  it's easiest
to explain with two of the functions i used to test this:

=================================================
static void *ct_seq_start(struct seq_file *s, loff_t *pos)
{
        loff_t *spos = kmalloc(sizeof(loff_t), GFP_KERNEL);
        printk(KERN_INFO "seq loaded, initial pos is %Ld.\n", *pos);

        if (!spos)
                return NULL;

        /*
         * It's *really* end of file when the position is greater than 25.
         */

        if (*pos > 25) {
                printk(KERN_INFO "seq start, bailing:  pos = %Ld.\n", *pos);
                return NULL;
        }

        *spos = *pos;
        return spos;
}

static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos)
{
        loff_t *spos = (loff_t *) v;
        *pos = ++(*spos);
        printk(KERN_INFO "seq next, current pos is %Ld.\n", *pos);

        if (((*pos) % 16) == 0) {       /* End of this "iteration". */
                printk(KERN_INFO "seq next, returning NULL.\n");
                return NULL;
        }

        return spos;
}
=================================================

  note how, for seq files, there are *two* routines that can pass back
a value of NULL to signify "end" -- the "start" routine and the "next"
routine -- but these two return values of NULL mean two different
things.

  in the "next" routine, returning NULL seems to mean that this is the
end of this *current* round of iterations when you're reading the
sequence file.  notice that i define that arbitrarily as every 16
iterations, at which point that round stops.

  at that point, in the normal course of reading the seq file, the
"start" routine is then *re-invoked* with a starting position of 16,
and things pick up where they left off for *another* round of 16 calls
to "show".  and so on, and so on.  and all of this happens with a
single call to something like "cat /proc/fubar".

  hands up, everyone who already knew that.  because i don't recall
ever seeing that being explained anywhere.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ