On Fri, May 05, 2000 at 01:54:08AM +0200, Andrea Arcangeli wrote:
> On Thu, 4 May 2000, H.J. Lu wrote:
>
> >Please don't make such an assumption. I don't know what stdio
> >will do on files under /proc. It may just call lseek.
>
> I'm not sure I'm the only one who does such assumption. Certainly
> /proc/memleak in the 2.3.x IKD does such assumption too and it's
> stightforward that way (however that's from me and MikeG too so maybe I'm
> really the only one who did this trick :).
>
> My argument is that without doing such assumption is not possible to
> support multiple reads in a /proc dynamic entry and being sure to read
> coherent data. When we return to userspace everything can happen to the
> hardware and when we return in kernel to read the next piece we can't
> guess anymore what fpos means. So stdio will never be reliable without
> such assumption. With such assumption don't do lseek or do it aware of the
> assumption.
>
> Could you tell me a good reason for which stdio should do a lseek while
> reading stright a file? Just to screwup kernel readahead?
>
lseek is used by stdio/iostream. Their implementations are free to call
it, if it is supported, whenever they think is appropriate. You can
disallow lseek on /proc, like pipe and tty. But if you allow lseek
on /proc, it has to do the right thing. Otherwise, I don't know
what will happen with stdio/iostream on /proc.
BTW, you can return -ESPIPE on /proc to disallow lseek.
-- H.J. Lu (hjl@gnu.org)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:17 EST