>>> On 16.06.17 at 17:28, <ta...@tklengyel.com> wrote:
> On Fri, Jun 16, 2017 at 9:15 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>>> On 16.06.17 at 16:26, <ta...@tklengyel.com> wrote:
>>> On Tue, May 30, 2017 at 3:46 AM, Petre Pircalabu
>>> <ppircal...@bitdefender.com> wrote:
>>>> Add support for filtering out the write_ctrlreg monitor events if they
>>>> are generated only by changing certains bits.
>>>> A new parameter (bitmask) was added to the xc_monitor_write_ctrlreg
>>>> function in order to mask the event generation if the changed bits are
>>>> set.
>>>>
>>>> Signed-off-by: Petre Pircalabu <ppircal...@bitdefender.com>
>>>
>>> Acked-by: Tamas K Lengyel <ta...@tklengyel.com>
>>
>> Are you btw in agreement with ...
>>
>>>> @@ -1107,6 +1107,11 @@ struct xen_domctl_monitor_op {
>>>> uint8_t sync;
>>>> /* Send event only on a change of value */
>>>> uint8_t onchangeonly;
>>>> + /*
>>>> + * Send event only if the changed bit in the control register
>>>> + * is not masked.
>>>> + */
>>>> + uint64_aligned_t bitmask;
>>
>> ... the 5-byte gap being introduced here, using of which won't
>> be possible without bumping XEN_DOMCTL_INTERFACE_VERSION
>> again? Generally we aim at making padding explicit and checking
>> it to be zero on input / providing zero on output.
>
> Yes, making the padding explicit would be better (but I'm not the
> maintainer of the domctl interface so my ack doesn't cover that).
Well, I have been waiting for a monitor maintainer ack to perhaps
give my own for the little bit of it where a REST maintainer one
would be needed. Irrespective of file level maintainership I think
the public interface parts still belong to their subsystems, and the
REST maintainer ack should normally be a purely mechanical last
step.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
