As long as Linux kernel creates the "Linux,stdout-package" property in the /chosen that indicates the console-path, then this script doesn't need to look at the "output-device" property in the /options node (the /options node represents the various NVRAM varaibles, which is how Open Firmware remembers it's console-path).
Two important testcases to worry about are: 1) If the "linux,stdout-package" property doesn't point to a vty device but something else like PCI graphics or PCI serial port (ATX platform has those). For a graphics card, the device tree node pointed by the stdout-package will have a "device-type" property of "display". I'm not sure what the compatible property will look like for PCI serial ports (as they'll be underneath the "pci-function" layer if there are multiple ports per PCI-function) but they'd map to ttyS# entries, not "hv*#" entries. Either way, it's safe to assume that if the "compatible" starts with hvterm, then it's either the hvterm, hvterm1, or hvterm-protocol (and maps to a hv*# entry). 2) If there are multiple USB keyboards (with graphics adapter), are both supported for login or just one? Hopefully both, but I guess this is a rare scenario. Note we've only been paying attention to stdout and not stdin to specify an exact keyboard. Then again, I'd advise staying away from specifying a specific keyboard because recent IBM firmware has a "/vdevice/vkbd" node (a virtual keyboard driver that handles USB hotplug gracefully), which doesn't map to a single USB keyboard. That function was added in Power5 GA7 firmware & JS21-GA3 blade firmware. - Jim Lindeman Software Engineer System p Firmware [EMAIL PROTECTED]
