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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.02.16 at 16:22, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> 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.

Are we not? They need to fit in 6 bits (unless we want to play tricks),
and numbers up to 27 are already in use.

Jan


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