lkml.org 
[lkml]   [2003]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: seq_file and exporting dynamically allocated data
Dear Harald,

The thing to be aware of is that seq API is limited to 1 page of data per
read(2) call. Some people loudly proclaim "seq API is unlimited, unlike
the old /proc formalism which was limited to 1 page" but they are
quiet about 1-page limitation for a single read(2) (due to hardcoded
kmalloc(size) in seq_file.c). Why is this important? Because if your
->start/stop routines take/drop some spinlocks then you have to know your
position and re-verify it on the next read(2) if your data is more than 1
page and thus could not be read atomically (i.e. while holding the
spinlocks).

The way I do it is by looking at the integer 'offset' parameter passed to
'start' and walk the linked list to the same 'distance' from the head (if
there is still anything that far) and verify if I am looking at the "same"
(in quotes because the concept of "same" has to be defined, not
with 100% accuracy :) element as it was at the end of the previous page.
The above was the only unpleasant complication with dealing with seq API.
The rest seemed very smooth and worked as expected. And the ->private
field of seq_file was very useful to maintain the information per open
instance of the file, i.e. per 'file' structure. I didn't understand why
it is not applicable in your case, but maybe I am missing the details of
your implementation or something like that.

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 13:58    [from the cache]
©2003-2011 Jasper Spaans