Re: [Qemu-block] KVM Forum block no[td]es

[Alberto Garcia]

On Fri 16 Nov 2018 04:18:34 PM CET, Kevin Wolf wrote:
> Am 16.11.2018 um 16:03 hat Alberto Garcia geschrieben:
>> > I don't think anything needs a way to generally block graph changes
>> > around some node.  We only need to prevent changes to very specific
>> > sets of edges.  This is something that the permission system just
>> > cannot do.
>> 
>> But what would you do then?
>
> I agree with you mostly in that I think that most problems that Max
> mentioned aren't readl. The only real problem I see with GRAPH_MOD as
> a permission on the node level is this overblocking - but that's bad
> enough that I feel using permissions to block changes to a whole node
> is not a good solution.

I understand that this restriction would be too coarse, but do you have
any case in mind where this would be a problem, or are you simply
worried because it's not an elegant solution?

(not that I'm resisting the proposal of using a counter, I'm just
curious)

> So what's the alternative? Max had a possible solution in the first
> email in this thread:
>
>> - A property of BdrvChild that can be set by a non-parent seems more
>>   feasible, e.g. a counter where changing the child is possible only
>>   if the counter is 0.  This also actually makes sense in what it
>>   means.
>
> The commit job would increment BdrvChild.block_change (or whatever we
> would call it) for all bs->backing edges in the subchain.

So instead of having a permission blocking changes in all of a node's
links, this would only affect the backing links.

It should work, I can give it a try.

Does it make sense to keep the GRAPH_MOD permission at all if we're not
really using it and we don't know what it is for? We can just drop it,
or are we breaking the API or the ABI?

Berto