Wesley Shao wrote:
> Garrett D'Amore wrote:
>> Zhijun Fu wrote:
>>> Garrett D'Amore wrote:
>>>> Personally, I find the new syntax and the new output a bit awkward
>>>> -- anyone not intimately familiar with the tool is going to have
>>>> trouble understanding what 0x1,0x8 means.
>>>>
>>>> I think I'd rather keep the two separate in the output, and add a
>>>> new switch (-p ?) for the "original" cpu id for x86 platforms.
>>> Thanks Garrett for the comments.
>>>
>>> On the input side, user need to uniquely specify which interrupt(s)
>>> to show/retarget,
>>> and on x86 platforms an interrupt will be uniquely identified by a
>>> (cpuid, vector#)
>>> pair, thus we choose this pair as a representation for an interrupt,
>>> something like
>>> 0x1, 0x8.
>>>
>>> Otherwise we'll have to add a new option for cpu and check for both
>>> options,
>>> -i <vector#> -p cpuid
>>> with this we have to verify and report error if users use one but
>>> not both,
>>> that could lower user friendly.
>>>
>>> Assuming the above, on the output side we'll need the new output
>>> as well to be to be consistent with the input side. That also works
>>> more friendly with scripts. And with examples in manpages probably
>>> it would be less a problem for new users to understand things like
>>> 0x1, 0x8. Or do you still fell strong enough that the original
>>> verbose output should be preserved?
>>
>> I'm not entirely sure I agree with your stance that adding a new
>> option is less user friendly, but I do see that having the tool
>> behave differently on SPARC vs. x86 would be unfortunate.
>>
>> Is there a way to encode the CPU in the vector number? Perhaps use a
>> value like x, where x = cpu * 256 + vector? (The question here is,
>> do users of this tool have any reason to care about the actual value
>> of the vector number?) If you encode the CPU into the vector number
>> numerically, then you can do this without really changing any of the
>> command line options or output formats, if you wanted to.
>
> Each device can have many MSIs with each MSI taking a unique vector
> on any given cpu. Without knowing exactly which vector on which cpu,
> the tool can't be sure which MSI is being addressed.
>
> In terms of encoding cpu number into vector numbers in general, it
> has been discussed within the project team extensively. It actually
> adds more obscurity. The cpu numbers don't have to be contiguous with
> cpu hotplug features, it can go way beyond 256 in to full 32-bit with
> some recent hardware evolution, and on top of that converting between
> hex and decimal becomes a challenge for users since the tool needs
> to follow the convention that default input format is decimal, 0x for
> hex, etc.
>
> The way we are heading on x86 platform, hardware and finally software,
> each vector belongs to a cpu. It would be meaningless to mention a
> vector number without knowing which logical cpu. I think the tool is
> doing the right thing to bundle them together.
Thanks Wesley. I think we've talked about this enough ... its got a +1
from me now.
- Garrett
>
> Wes
>
>>
>> - Garrett
>>>
>>> Thanks,
>>> Robin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> - Garrett
>>>>
>>> Thanks for the suggestion, Garrett.
>>>
>>> On x86 an interrupt will be uniquely identified by a (cpuid,
>>> vector#) pair,
>>> thus 0x1,
>>>
>>>
>>>
>>
>
