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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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.
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.

> 
> Ian.
> 

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