[lkml]   [2003]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: seq_file and exporting dynamically allocated data
On Sat, 15 Nov 2003 wrote:
> If you mean that read(2) can decide to return less than full user buffer even
> though more data is available - tough, that's something userland *must* be
> able to deal with.

I think I now understand better what you mean. And that is not what I
meant. Yes, of course userspace must be able to deal with less data than
what it asked for. I agree.

But I was referring to the complication on the kernel side, whereby if the
data (collectively, all the entries) is more than 1 page then ->stop()
must be called and a page returned to user and then the kernel must build
another page but all it knows is the integer 'offset'. Anything could have
happened to the list (task list in this case) since ->stop() routine
dropped the spinlock. So, it is not obvious from which position to
start building the data for the new page.

Looking at mm/slab.c implementation I see that it just walks the integer
distance from the head of the list. Simple but not 100% correct, I think.
I.e. it can miss an entry if the list has changed between two read(2)s.

Kind regards

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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