[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/2] libvchan: replace munmap with correct xc_gntshr_munmap
On 10/05/13 15:08, Ian Campbell wrote: On Fri, 2013-05-10 at 14:55 +0100, Marek Marczykowski wrote:On 10.05.2013 15:46, Ian Campbell wrote:On Wed, 2013-05-08 at 15:08 +0100, Marek Marczykowski wrote:On 08.05.2013 15:49, Daniel De Graaf wrote:On 05/04/2013 06:10 PM, Marek Marczykowski wrote:On linux it will end up in munmap anyway, but do not assume any particular xc_gntshr_munmap implementation details. Signed-off-by: Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx>On a client, this ends up using xc_gntshr_munmap to unmap pages that were mapped with xc_gnttab_map_* instead of using xc_gnttab_unmam George: unless there is another OS besides Linux that implements the xc_gntshr_* interfaces (I found none from a grep of the source), this is just code clean-up and so could be postponed to 4.4.This is actually prerequirement for libvchan for mini-os (already posted v1, working on v2). But as mini-os libvchan isn't targeted for 4.3, this one also can wait.Is the first patch "libxc: fix xc_gntshr_munmap semantic" also included in this assessment? Message-Id: <20130508040327.91296310@xxxxxxxxxxxxxxxxx>As long as libxenvchan is the only (at least I'm aware of) user of xc_gntshr_munmap - probably yes. But IMO it's better to fix xc_gntshr_munmap sooner than later, to minimize changes in code that uses it (if someone will start to use it before 4.4 release).I'm not sure if you are arguing for or against putting that fix into 4.3? I read this as, "We should make the interface more useful in case someone decides to use it after 4.3 comes out but before 4.4 comes out." To which my response was, if this is in libxc, people shouldn't be linking against it anyway. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |