Re: seq_file and exporting dynamically allocated data

[viro]

On Sun, Nov 16, 2003 at 07:27:23AM +0000, Tigran Aivazian wrote:
> Hi Al,
> 
> I remembered the other two areas where, maybe, seq API can be slightly 
> improved:
> 
> a) no "THIS_MODULE" style module refcounting, so I had to do manual 
> MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT in ->open/release. I am aware of the 
> deficiencies of this approach, of course (it's been discussed too many 
> times in the last several years).

	You don't need to do that.  Look, these ->open() and ->release()
are not some new methods - they are ->open() and ->release() of your
struct file.  The fact that they happen to call functions from seq_file.c
doesn't change anything - they are struct file methods, sitting in some
instance of struct file_operations.  And just as with any such instance,
you have ->owner in struct file_operations.  Which will be honoured by
open(2) - just as with any other file.

	IOW, there is no need for any special rmmod protection of iterator.
Normal protection of file methods will be enough - after all, even if
iterator is not in the same module, the code in our ->open() directly
refers to it.  I.e. we have a direct dependency and as long as module
where our file_operations are is there, the module with our iterators
will stay around.
 
> b) no way to reset the 'offset' to 0 when the ->next() detects that it is
> back at the head of linked list, i.e. when it should return NULL. It's OK

Let me get it straight - you want an infinite file, with no EOF anywhere
and contents more or less repeating itself?  _And_ you want a working
lseek() on that?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/