cvs commit: src/sys/conf files src/sys/dev/uart uart_cpu.h uart_cpu_alpha.c uart_cpu_amd64.c uart_cpu_i386.c uart_cpu_ia64.c uart_cpu_pc98.c uart_cpu_sparc64.c uart_subr.c

[John-Mark Gurney]

Marcel Moolenaar wrote this message on Fri, Mar 19, 2004 at 18:14 -0800:
>   The reasons for introducing these variables are:
>   1.  Hints have side-effects. They reserve the unit number for use by
>       isa or acpi devices and therefore cannot be used to select a pci
>       device. Also, the use of a unit number to select a device prior

see below..  Hints are SUPPOSE to reserve a unit number of any bus...

>       to bus enumeration is nonsense. The new variables have no side-
>       effects and are not based on unit numbers.
>   2.  Hints don't have the expression power to allow the sysadmin to
>       select UARTs that are not legacy PC devices and need the support
>       of compile-time constants to give the sysadmin some level of
>       flexibility.

Hun? I don't follow this one?  Hints are suppose to be bus generic
methods of tieing down any device on the subsystem so that you know
exactly the correct device between reboots...  If PCI adn/or other
busses don't understand hints, then this is a bug in the bus and
should not introduce a new method of providing hints...

>   The hw.uart.console and hw.uart.dbgport variables specify a list of
>   attributes. An attribute is a tag-value pair, seperated by a colon.
>   Attributes are seperated by a comma. Where possible, tags are the
>   same as those in /etc/remote (only br and pa in practice). Details
>   can be found in the manpage (not part of this commit).

I don't see how this prevents problems with probe order suddenly changing
and you don't have the same console you thought you had...  also, how
do you handle this before devfs is up?

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."