lkml.org 
[lkml]   [2003]   [Nov]   [17]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 17 Nov 2003 08:38:24 +0000 (GMT)
FromTigran Aivazian <>
SubjectRe: seq_file and exporting dynamically allocated data
On Mon, 17 Nov 2003, William Lee Irwin III wrote:

> On Mon, Nov 17, 2003 at 08:21:34AM +0000, Tigran Aivazian wrote:
> > Now, since there is no way to detect EOF, other than by reading an extra 
> > page and discovering that it belongs to the next iteration, we have to do 
> > the lseek(fd, 0, SEEK_SET) anyway.
> > So, the "auto-rewinding" read would only help the cases where application 
> > doesn't need to differentiate between samples and is happy to just 
> > continuously read chunks packed into pages one by one as fast as 
> > possible. In this case it doesn't need to lseek to 0, so auto-rewinding on 
> > kernel side would prevent it from slowing down.
> 
> If you're going to repeatedly read from 0 pread() sounds like a good
> alternative to read() + lseek(), plus no kernel changes required to
> get rid of the lseek().

The reason why I didn't use pread(2) is because I have to do multiple
calls to read(2). There is no way that I know of to pack more than a
single page into a single read(2) with seq_file API.

Yes, I remember Al saying "it's not a page" but in practice it still
appears to be limited to a page unless someone shows a sample seq_file
module which can provide more than a page of data on a single read(2). The
implementations I have looked at in the kernel (e.g. mm/slab.c) are
limited to a single page per read(2).

Kind regards
Tigran

-
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 12:58    [from the cache]
©2003-2008