* Luck, Tony <tony.luck@xxxxxxxxx>: > > A while back, I submitted a patch to expose the value of the _SUN > > method for CPUs. On ia64, the "physical id" field in > > /proc/cpuinfo isn't sufficient for some legacy HP ia64 platforms, > > as they do not have a modern SAL or PAL. > > Do these legacy systems with ancient SAL/PAL actually support > processor hot plug? No, they do not; that was simply the most convenient / obvious example I could think of for someone reading changelogs a few years later and wondering why we created this sysfs attribute. A real world example would be HP managability software keeping track of CMC/CPE data for CPUs over a long period of time for the purpose of doing long-term failure analysis. This software can already grab a bunch of info from IPMI, such as CPU serial number, date code, physical location, but cannot correlate it to the kernel's idea of logical CPU number and physloc. Having the kernel expose the physical slot ties it all together. This example is something any vendor selling higher level managability software might want to do, and specifically HP wants to do it to take care of our customers who have large deployments of these legacy systems. Hopefully that is enough justification to warrant at least looking at the patch and telling me why it sucks. ;) > Perhaps this next rant is beyond the scope of Linux architecture > and more on overall systems useabilty. It is just asking for > trouble to print a message on the console telling the user to go > pull out the board in "slot 2". Do the slot numbers count from > "0" or from "1"? Are they numbered left-to-right or right-to-left? > What if the rack is non-standard so the system was rotated 90 > degrees? Now are they numbered top-to-bottom or bottom-to-top. Well, at least for HP ia64 machines, we have lots of silk-screening on the backplane, as well as pretty diagrams on chassis covers, and we took care in making sure our what our firmware matches up with those pictures. But in general, I like the idea of das blinkenlights too. :) > Best idea is to have a (blinking) (red) light on the board and > instruct the operator to pull out the board with the fail-light > (but even then a red-green colour blind operator will still > mess it up for you and pull the wrong board :-) Heh, then just make the failure light either blink (for failure) or not blink (default). Then as long as the operator can detect lumens, he/she would just be able to pull the blinky board. :) Thanks. /ac -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
