Re: seq_file and exporting dynamically allocated data

From: viro
Date: Mon Nov 17 2003 - 00:53:28 EST


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/