Re: [Xen-devel] [PATCH LINUX RFC] xen: privcmd: implement IOCTL_PRIVCMD_MMAPBATCH_V2_UNCACHED

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-12-20 at 09:38 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 20, 2013 at 02:18:48PM +0000, Ian Campbell wrote:
> > On Fri, 2013-12-20 at 09:13 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Dec 20, 2013 at 09:19:13AM +0000, Ian Campbell wrote:
> > > > On Wed, 2013-12-18 at 16:16 -0500, Konrad Rzeszutek Wilk wrote:
> > > > > On Wed, Dec 18, 2013 at 05:30:37PM +0000, Ian Campbell wrote:
> > > > > > On ARM we want to use uncached foreign mappings while building the 
> > > > > > domain
> > > > > > because the guests start with MMU and caches disabled.
> > > > > > 
> > > > > 
> > > > > Why introduce a new ioctl? Could we piggyback on the old one and on 
> > > > > ARM
> > > > > do the uncached.
> > > > 
> > > > Because there are (going to be) other circumstances where we do want a
> > > > cached foreign mapping, specifically migration.
> > > 
> > > Why not then just expand the existing ioctl with a flag? ARM after all
> > > is still experimental so you could do that.
> > 
> > Well, ARM just uses the same ioctl as on x86, so we wouldn't be
> > expanding, but duplicating, which didn't seem worth it.
> > 
> > And secondly, unlike hypercalls, the ioctls are part of Linux's
> > interface, so I'm not sure how changing them would go down.
> 
> You wouldn't break - expanding the structure still preserves the ABI.

The ioctl number includes sizeof(the struct) though, so changing the
struct would mean adding compatiblity handling for the old struct,
binding the old and new numbers, and all that jazz.

> Only more recent toolstacks would know how to use it.
> 
> 
> But I get your point - you are hesistant to modify it the existing one.
> How about making this new more flexible - perhaps have a 'flag' and
> 'version' or even 'size' to account for changes? And call it IOCTL_.._V3
> which would allows us to add more things in the future (depending on the
> version size)? That way if something else likes this pops up we have
> a nice escape vehicle ready.

I think I remember Andy cooper saying he wanted to do a more thorough
revamp of the API at some point (I can't recall why), so I wanted to
keep this extension as small as possible rather than create a new thing
in the mean time.

Ian.


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