On 01/22/2015 02:50 PM, Tamas K Lengyel wrote: > On Thu, Jan 22, 2015 at 1:43 PM, Tim Deegan <t...@xen.org> wrote: >> Hi, >> >> At 16:17 +0100 on 18 Jan (1421594274), Tamas K Lengyel wrote: >>> From: Razvan Cojocaru <rcojoc...@bitdefender.com> >>> >>> The public mem_event structures used to communicate with helper >>> applications via >>> shared rings have been used in different settings. However, the variable >>> names >>> within this structure have not reflected this fact, resulting in the reuse >>> of >>> variables to mean different things under different scenarios. >>> >>> This patch remedies the issue by clearly defining the structure members >>> based on >>> the actual context within which the structure is used. >>> >>> Signed-off-by: Razvan Cojocaru <rcojoc...@bitdefender.com> >>> Signed-off-by: Tamas K Lengyel <tamas.leng...@zentific.com> >> >> This looks like a nice improvement. If everyone who commented about >> making ABI changes is happy with it, I am too. >> >> It would be nice if you could add some comments to the new struct >> definitions saying what the various fields mean (e.g. when the event >> triggers and what the fields will contain). > > Ack, will do! > >> >> One nit in the patch itself: >> >>> @@ -592,13 +592,12 @@ int main(int argc, char *argv[]) >>> } >>> >>> >>> - rsp.gfn = req.gfn; >>> - rsp.p2mt = req.p2mt; >>> + rsp.mem_access_event.gfn = req.mem_access_event.gfn; >> >> You're dropping a p2mt update here. Is that an oversight? >> With the obvious equivalent update inserted, > > No, it is not. That field is only used by mem_sharing and mem_paging, > not by mem_access.
Ah, I stand corrected. I've checked agains my original patch, but the series also separates the mentioned areas. Sorry for the noise, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
