Hi Steve,
On 07/08/14 14:32, Steven Whitehouse wrote:
Hi,
On 07/08/14 13:58, Rob Jones wrote:
[snip]
On a related subject, Having looked at a few uses of seq_file, I must
say that some users seem to make assumptions about the internal
workings of the module. Dangerous behaviour as only some behaviours are
documented.
e.g. The behaviour that "struct seq_file" pointer is stored in
file->private_data is documented and can therefore be relied upon but
the fact that the output buffer and its size are only defined at the
first output (and can therefore be pre-defined and pre-allocated by
user code) is not documented and could therefore change without warning.
This second behaviour is assumed in, for example, module fs/gfs2/glock.c
which could, therefore, stop working properly without warning if the
internal behaviour was changed.
While it is undocumented, it is I understand, how this feature was
intended to be used, so I think that it is safe to do this in the GFS2
case. Here is a ref to the thread which explains how it landed up like
that:
https://www.redhat.com/archives/cluster-devel/2012-June/msg00000.html
No criticism was intended of that particular piece of code, It has been
there for a couple of years and is, presumably, still working :-)
It was just a general point about things needing to be written down. A
behaviour such as you were relying on can be a very positive thing but
it would be of much greater use if it was written down in the file docs.
I completely missed seq_file_private() because I was looking at the
docs more than the code. If it had been written down in the docs it
would have saved me quite a bit of time, similarly, if the buffer
allocation behaviour was documented, changes to seq_file.c would not be
made that could break your code.
God knows, I'm not a fan of unnecessary documentation but where it's
useful I'm all for it.
Steve.
--
Rob Jones
Codethink Ltd
mailto:rob.jones@xxxxxxxxxxxxxxx
tel:+44 161 236 5575
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
