On Wed, 5 Aug 2009, Bruce Rowen wrote:
> On Aug 5, 2009, at 9:34 AM, Robert P. J. Day wrote:
> i'm still somewhat confused here. in every example using a seq_file
> that i've ever seen, it's *assumed* that the very first call to the
> start() routine is going to pass a (*pos) value of zero, which is used
> to signify the initial call to that start routine. that *has* to be
> consistent. if it can be something other than zero for that *initial*
> call, how would seq_files ever be guaranteed to work properly?
>
>
> I pulled this from fs/proc/devices.c, I hope it's version compatible with
> your query:
>
> static void *devinfo_start(struct seq_file *f, loff_t *pos)
>
> 27 {
> 28 if (*pos < (BLKDEV_MAJOR_HASH_SIZE + CHRDEV_MAJOR_HASH_SIZE))
> 29 return pos;
> 30 return NULL;
> 31 }
>
> This example does not assume (*pos) is initialized to zero. Digging
> further back into the sequence of events that occurs before the
> start() is called, I can't find anything that explicitly sets the
> (*pos) to zero, unless it follows philosophy of setting ( *pos) to
> zero when open() is called (this is probably buried in the more
> generic file I/O layers).
i think we're actually agreeing here. the seq_file start routine
doesn't technically assume an initial pos of zero, but for the overall
operation to work properly, *something* has to initialize that to
zero, almost certainly further down in the open code.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
"Kernel Newbie Corner" column @ linux.com: http://cli.gs/WG6WYX
========================================================================
