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.
- Garrett
>
> Thanks,
> Robin
>
>
>
>
>
>
>
>
>>
>> - Garrett
>>
> Thanks for the suggestion, Garrett.
>
> On x86 an interrupt will be uniquely identified by a (cpuid, vector#)
> pair,
> thus 0x1,
>
>
>
