Messages in this thread | | | Date | Mon, 17 Nov 2003 05:48:20 +0000 | From | viro@parcelfa ... | Subject | Re: seq_file and exporting dynamically allocated data |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |