From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH XEN v8 20/29] tools/libs/gnttab: Extensive updates to API documentation. Date: Tue, 19 Jan 2016 13:24:11 +0000 Message-ID: <20160119132411.GY1691@citrix.com> References: <1452864168.32341.97.camel@citrix.com> <1452864188-2417-1-git-send-email-ian.campbell@citrix.com> <1452864188-2417-21-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1452864188-2417-21-git-send-email-ian.campbell@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: wei.liu2@citrix.com, Daniel De Graaf , ian.jackson@eu.citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, Jan 15, 2016 at 01:22:59PM +0000, Ian Campbell wrote: > In particular around error handling, behaviour on fork and the unmap > notification mechanism. > > Behaviour of xengnttab_map_*grant_refs and xengntshr_share_pages on > partial failure has been confirmed/inferred (by inspection) on Linux > and Mini-os (the only two known implementations. Likewise the > behaviour of the notification mechanism has been confirmed/inferred > (by inspection) of the Linux implementation (currently the only > implementation) and libvchan (primary known user). > > These updates are not folded into "tools: Refactor > /dev/xen/gnt{dev,shr} wrappers into libxengnttab." to try and reduce > the amount of non-movement changes in that patch. > > While I'm not convinced by javadoc/doxygen cause the existing comments > which appear to use that syntax to have the appropriate /** marker. > > Also fix a typo in a code comment. > > Signed-off-by: Ian Campbell > Reviewed-by: Daniel De Graaf > Cc: Daniel De Graaf Since Daniel and Ian have done in depth review of this so I only skim it this time. It looks sensible to me: Acked-by: Wei Liu (one typo below) [...] > + * > + * NOTE: this protocol is intended to allow for better error behaviour > + * and recovery between two cooperating peers. It does not cover the > + * case of a malivious peer who may continue to hold resources open. "malicious"