It seems like ~any port of netbsd has a different way to decide which device
to use for console input and output.

This has been no large problem, since most drivers for such devices (or at
least their bus attachements) have been in very MD directories (for example
sys/src/dev/sun/kbd.c).

It is, however, a problem for PCI and USB devices (and probably some other
classes I overlooked right now).

See for example the recently added sys/dev/pci/machfb driver. It has to
decide at attach time if it is going to be the output part of the console.
At least that is the way it works now, and the ramifications of changing
this are not at all clear to me.

To make this decision possible without MD code in the concrete PCI driver,
I see two options:

 (1) add a "is console or should become console, if possible" flag to
     the attach args.

This would be set for the right device on sparc ports, where the firmware node
is known in advance and the correct value can be entered into the attach args,
or maybe always set to true on ports like i386, where the first device wins
console, and be set to false if console is already claimed.

 (2) add a MI API with MD implementation, called by the MI driver to decide
     if it should attach console

On sparc64 this could be 

  int device_is_console(bus_space_tag_t t, bus_space_handle_t h)

and i386 would always define it to return 1 if no console is yet present.

I have no idea wether other ports could decide this given a tag/handle, or if
we need to add more args.

To me variant (1) looks cleaner. We can add this attach arg member to any bus
that can attach a console on some port, as soon as we get a driver for that
console device. All other drivers would ignore that struct member anyway.

Of course a third option is to leave everything as is.

Martin