[Cluster-devel] [PATCH 02/13] GFS2: Make do_xmote determine its own gh parameter

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,


On 19/11/18 21:06, Bob Peterson wrote:
> Hi Steve,
>
> ----- 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 <rpeterso@redhat.com>
> (snip)
>
>> 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
>> find_first_waiter() call,
>>
>> Steve.
> 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.
A function can't become a state in this sense. The state in this case is 
the content of struct gfs2_glock, and the
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.
>
> Regards,
>
> Bob Peterson

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,

Steve.