[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH LINUX RFC] xen: privcmd: implement IOCTL_PRIVCMD_MMAPBATCH_V2_UNCACHED
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |