Re: [Xen-devel] [PATCH v7 2/5] sysctl: Add sysctl interface for querying PCI topology

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.04.15 at 14:56, <boris.ostrovsky@xxxxxxxxxx> wrote:

> On 04/21/2015 03:01 AM, Jan Beulich wrote:
>>>>> On 17.04.15 at 18:59, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> Changes in v7:
>>> * Break from the loop when -ENODEV is encountered
>> This seems pretty inefficient for the caller. Returning a "bad"
>> identifier other than XEN_INVALID_NODE_ID would seem better
>> to me.
> 
> That would mean that there is really no reason to return -ENODEV, which 
> I thought you wanted to see. In that case (i.e. if no error needs to be 
> returned) yes, a new token would make things simpler.

All I asked for was to make the two cases (no device and device
with no known node) distinguishable.

>>> --- a/docs/misc/xsm-flask.txt
>>> +++ b/docs/misc/xsm-flask.txt
>>> @@ -121,6 +121,7 @@ __HYPERVISOR_sysctl (xen/include/public/sysctl.h)
>>>    * XEN_SYSCTL_cpupool_op
>>>    * XEN_SYSCTL_scheduler_op
>>>    * XEN_SYSCTL_coverage_op
>>> + * XEN_SYSCTL_pcitopoinfo
>> No additions to this list are permitted. Either the new sub-op is
>> disaggregation safe (which it looks to be), or it can't be accepted.
> 
> True, it *is* safe, but why then cputopoinfo and numainfo are in this 
> list? They look to be safe as well.

Because at the time the list got composed we weren't able to
spend time looking at _all_ of the operations, and hence we
simply added them all (with a few exceptions on the domctl side
iirc). Quite likely the two you mention could be removed from
the list, but such needs to happen with proper reasoning in the
patch description. Feel free to submit a patch.

Jan


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