lkml.org 
[lkml]   [2001]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH][RFC] Re: 2.4.15-pre5: /proc/cpuinfo broken
Date
Followup to:  <Pine.GSO.4.21.0111171359410.11475-100000@weyl.math.psu.edu>
By author: Alexander Viro <viro@math.psu.edu>
In newsgroup: linux.dev.kernel
>
> On Sat, 17 Nov 2001, Linus Torvalds wrote:
>
> >
> > On Sat, 17 Nov 2001, Alexander Viro wrote:
> > >
> > > Frankly, I'd prefer to try (b) before reverting to (a). Patch doing that
> > > variant follows. Linus, your opinion?
> >
> > (d) make seq_file have my originally suggested "subposition" code.
> >
> > Ie make the X low bits of "pos" be the position in the record, with the
> > high bits of "pos" being the current "record index" kind of thing.
> >
> > That makes lseek() happy.
>
> It will not help. lseek() in question is relative and crosses the
> record boundary. I.e. we have
>
> n = read(fd, buf, ...);
> /* process k bytes */
> lseek(fd, k-n, SEEK_CUR);
>
> and that will break just as the current variant does. It's not about
> seek to remembered position - it's a relative seek to calculated offset.
> Calculated from number of bytes returned by read().
>

We may really want to consider if we want /proc entries to be
S_IFREG(). The closest equivalent I can think of is really a
character device node (S_IFCHR) more so that S_IFIFO.

-hpa

--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.106 / U:1.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site