Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

[Tamas Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Tue, Aug 2, 2016 at 10:13 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 02.08.16 at 18:06, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>> On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx> 
>> wrote:
>>> On Aug 2, 2016 06:45, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> >>> On 01.08.16 at 18:52, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>>>> > +int hvm_monitor_mem_access(struct vcpu* v, bool_t sync,
>>>> > +                           vm_event_request_t *req)
>>>> > +{
>>>> > +    return monitor_traps(v, sync, req);
>>>> > +}
>>>>
>>>> Overall - is this a useful wrapper? Why can't the caller(s) call
>>>> monitor_traps() directly? And if you really want to keep it, it would
>>>> probably better be an inline one.
>>>
>>> The reason for this wrapper is to avoid having to include the common monitor
>>> header here. I can move it into the hvm monitor header as inline, that's no
>>> problem.
>>
>> Actually, making it into inline would require that hvm/monitor.h
>> include the common monitor.h as well, at which point having the
>> wrapper would be useless as hvm.c would have effectively include
>> common monitor.h too. So yea, the goal is to avoid having to include
>> both common/monitor and hvm/monitor in hvm.c and it needs this kind of
>> wrapper.
>
> But what's wrong with including a header that declares a function you
> want to call?
>

Nothing really, just wanted to separate things more neatly into their
appropriate locations. It might be an overkill though I admit..

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel