On 19/11/18 21:06, Bob Peterson wrote:
A function can't become a state in this sense. The state in this case is
the content of struct gfs2_glock, and the
----- Original Message -----
On 19/11/18 13:29, Bob Peterson wrote:
This is another baby step toward a better glock state machine.
Before this patch, do_xmote was called with a gh parameter, but
only for promotes, not demotes. This patch allows do_xmote to
determine the gh autonomously.
Signed-off-by: Bob Peterson <rpete...@redhat.com>
Since gh is apparently only used to get the lock flags, it would make
more sense just to pass the lock flags rather than add in an additional
Perhaps I didn't put enough info into the comments for this patch.
I need to get rid of the gh parameter in order to make the glock
state machine fully autonomous. In other words, function do_xmote will
become a state in the (stand alone) state machine, which itself does not
require a gh parameter and may be called from several places under
several conditions. The state of the glock will determine that it needs
to call do_xmote, but do_xmote needs to figure it out on its own.
functions define how you get from one state to another,
Before this patch, the caller does indeed know the gh pointer, but in
the future, it will replaced by a generic call to the state machine
which will not know it.
That is not relevant to the point I was making though. The point is that
if the flags are passed to do_xmote rather than the gh, then that
resolves the issue of needing to pass the gh and reduces the amount of
code, since you can pass 0 flags instead of NULL gh,