[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |