[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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.