Date: Sat, 20 Mar 2004 10:56:40 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: cvs-all@FreeBSD.org Subject: Re: 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 Message-ID: <20040320185640.GD567@funkthat.com> In-Reply-To: <20040320085431.GA74398@dhcp01.pn.xcllnt.net> References: <200403200214.i2K2E3ps052217@repoman.freebsd.org> <20040320080027.GC567@funkthat.com> <20040320085431.GA74398@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote this message on Sat, Mar 20, 2004 at 00:54 -0800:
> > > 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...
>
> Hints are used to tell the kernel about possible devices in case
> the kernel can not reliably detect them itself. This typically
> applies to the ISA bus. Any bus that allows enumeration does not
> need to have hints.
better not let the scsi code know about this.. everyone that is using
hints to hardwire their scsi drives even though scsi can reliably detect
them itself might stop working...
> > > 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?
>
> Probe order is irrelevant if you specify the device by its I/O port
> or memory mapped I/O address. When you need to pinpoint a device
> prior to any form of bus enumeration, the unit number is meaningless
> and any mechanism that includes a unit number is bogus. That's why
> hints are the wrong tool for pinpointing a console or debug port.
I hope that you don't have to specify the console via io/memory port..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040320185640.GD567>