Messages in this thread | | | Date | Sat, 15 Nov 2003 20:50:55 +0000 (GMT) | From | Tigran Aivazian <> | Subject | Re: seq_file and exporting dynamically allocated data |
| |
On Sat, 15 Nov 2003 viro@parcelfarce.linux.theplanet.co.uk 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 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/
| |