[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access



Ian Campbell writes ("Re: [PATCH v2 1/2] altp2m: Merge 
p2m_set_altp2m_mem_access and p2m_set_mem_access"):
> It's unfortunate that we've found ourselves here, but I think rather than
> deprecating the current and adding a new op alongside we should just accept
> the one-time fragility this time around, add the version field as part of
> this set of changes and try and remember to include a version number for
> next time we add a tools only interface. I don't think xenaccess is yet
> widely used outside of Tamas and the Bitdfender folks, who I would assume
> can cope with such a change.

I'm not sure what a separate version number buys us.

> I could accept changing the op number would make sense, but I don't think
> we should deprecate the old one (which implies continuing to support it in
> parallel), if we go this route we should just retire the old number to
> straight away to return -ENOSYS (or maybe -EACCESS, which is what a version
> mismatch would have resulted in).

If we simply want to detect the mismatch that seems like the best
approach.

It's not like we're short of memory op values.

Ian.

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


 


Rackspace

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