On Tue, Aug 2, 2016 at 10:13 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>> On 02.08.16 at 18:06, <tamas.leng...@zentific.com> wrote: >> On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel <tamas.leng...@zentific.com> >> wrote: >>> On Aug 2, 2016 06:45, "Jan Beulich" <jbeul...@suse.com> wrote: >>>> >>> On 01.08.16 at 18:52, <tamas.leng...@zentific.com> 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@lists.xen.org https://lists.xen.org/xen-devel