On 07/08/14 15:22, Steven Whitehouse wrote:
Hi,
On 07/08/14 15:16, Rob Jones wrote:
On 07/08/14 15:09, Rob Jones wrote:
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
Sorry, that should be seq_open_private()
Why does one never see the mistake until *after* hitting send?
Always the way, unfortunately!
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.
Yes, very much agreed, and no doubt it would be useful in this case. I
hoped that the earlier thread might be a useful starting point, since it
explained some of the whys and wherefores,
Well, I'm making a start by documenting seq_open_private(). Small
steps :-)
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
