Date: Sun, 16 Nov 2003 07:27:23 +0000 (GMT)
From: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
To: viro@parcelfarce.linux.theplanet.co.uk
cc: Harald Welte <laforge@netfilter.org>, <linux-kernel@vger.kernel.org>
Subject: Re: seq_file and exporting dynamically allocated data
In-Reply-To: <Pine.LNX.4.44.0311152135370.743-100000@einstein.homenet>
Message-ID: <Pine.LNX.4.44.0311160717250.765-100000@einstein.homenet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1647
Lines: 37

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).

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
for a user app to detect that (e.g. check proc->pid == 0 thus it's a
"swapper"  and so the beginning of the next chunk of processes) but it
also has to issue lseek(fd, 0, SEEK_SET), otherwise the offsets will keep
growing larger and larger and the kernel has to loop around that list (in
->start() when it tries to walk a set distance from the head) many times
unnecessarily and so the performance goes down. I tried doing something
like this:

  m->index = m->count = m->from = *ppos = 0;

in the ->next() function whenever it detects that the 'next' element is 
'init_task' but it didn't help. And I understand why, i.e. read(2) really 
is supposed to increment the offset correctly, so what I require would 
break the normal Unix read(2) semantics. So, maybe forcing user app to 
issue lseek(fd, 0, SEEK_SET) is the only sensible solution... If you have 
better ideas, please let me know.

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/