- Change the code that determines whether to use a serial console and

  which serial device to use in that case respectively to not rely on
  the OFW names of the input/output and stdin/stdout devices. Instead
  check whether input and output refers to the same device and is of
  type serial (uart(4) was already doing this) and for the fallback
  to a serial console in case a keyboard is the selected input device
  but unplugged do the same for stdin and stdout in case the input
  device is nonexistent (PS/2 and USB keyboards) or has a 'keyboard'
  property (RS232 keyboards). Additionally also check whether the OFW
  did a fallback to a serial console in the same way in case the
  output device is nonexistent. While at it save on some variables
  and for sys/boot/sparc64/loader/metadata.c move the code in question
  to a new function md_bootserial() so it can be kept in sync with
  uart_cpu_getdev_console() more easily.
  This fixes selecting a serial console and the appropriate device
  when using a device path for the 'input-device' and 'output-device'
  OFW environment variables instead of an alias for the serial device
  to use or when using a screen alias that additionally denotes a
  video mode (like e.g. 'screen:r1024x768x60') but no keyboard is
  plugged in (amongst others). It also makes the code select a serial
  console in case the OFW did the same due to a misconfiguration like
  both 'input-device' and 'output-device' set to 'keyboard' or to a
  nonexisting device (whether the OFW does a fallback to a serial
  console in case of a misconfiguration or one ends up with just no
  console at all highly depends on the OBP version however).
- Reduce the size of buffers that only ever need to hold the string
  'serial' accordingly. Double the size of buffers that may need to
  hold a device path as e.g. '/pci@8,700000/ebus@5/serial@1,400000:a'
  exceeds 32 chars.
- Remove the package handle of the '/options' node from the argument
  list of uart_cpu_getdev_dbgport() as it's unused there and future
  use is also unlikely.

MFC after:	1 week

0 files changed, 0 insertions, 0 deletions