Re: [Xen-devel] [PATCH v2 2/2] libvchan: replace munmap with correct xc_gntshr_munmap

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-05-10 at 15:15 +0100, George Dunlap wrote:
> 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.

OK. Strictly speaking you mean "shouldn't rely on the libxc API not
changing", we don't forbid people to link against libxc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel