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. 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, >> >> >> >
