Date: Thu, 3 Aug 2006 21:30:22 GMT From: Warner Losh <imp@bsdimp.com> To: freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Message-ID: <200608032130.k73LUM8g029837@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/100831; it has been noted by GNATS.
From: Warner Losh <imp@bsdimp.com>
To: marcel@xcllnt.net
Cc: nate@root.org, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org,
freebsd-i386@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports -
bounty offered
Date: Thu, 03 Aug 2006 15:28:16 -0600 (MDT)
> On Aug 3, 2006, at 10:12 AM, Warner Losh wrote:
>
> > The "minor logic" in newbus is actually kicking my ass right now. I
> > have stuff in p4 that should implement all the things we need, but the
> > unit allocation is kicking my butt. I fear that the only real way is
> > to subclass isa three times: hints-only, pnp+hint-augment,
> > acpi+hint-augment. In the latter two, how does one tell a 'this hint
> > is for a card that's there' versus a 'this hint is a wiring hint'?
> > And for the wiring hints, how much of the device matching do you do?
> > If the I/O matches, but the IRQ doesn't, is that a match? What about
> > vice versa?
>
> Like I said before: hints are abused for way too many purposes.
> It's better to come up with a new scheme where you clearly separate
> the different functions we're looking for and design *as many*
> different mechanisms to implement these functions.
The only thing that's not well suited for hints is the 'what is my
console' function. The others can be made to work well with only a
few engineering compromises :-). I'll agree that the flags in sio
used to specify which UNIT is the console is lame and should be
replaced with a generalization of the uart method.
> One approach would be to make ACPI unconditional, as it's there
> to describe the existence of legacy devices and thus serves the
> same purpose as our current hints and define hints to *only*
> allow wiring down hardware to unit numbers. These can be called
> hints because I'm sure we can not always guarantee it.
ACPI unconditional can't happen. There are many machines being made
today that simply do not implement ACPI. I have several boards at
work that implement PNPBIOS, but don't implement ACPI. These are
boards that are brand new. I think ACPI is an extra cost option, but
I might be confusing things. We do need to deal with cases like this
because they are common enough that we'll alienate folks embedding
FreeBSD if we take such a course.
> Marking devices as special, like the sio flags is an entirely
> different function alltogether and should therefore not be done
> with the same hints. That would just create the convolution, so
> you create different hints for that.
Agreed. However, the sio flags to designate a unit as console is the
only thing that doesn't fit well with hints, as presently implemented.
It should really be something like: console.type={serial,video}
console.location=<io=xxx,mem=yyy>
so that would could use a video card not mapped to the default address
as the console, etc. It would be up to the driver at attach time to
look at the available console meta-information to see if this driver
matches that information. Then it wouldn't matter for a serial
console point of view what driver unit is assigned. It might matter
for other reasons...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608032130.k73LUM8g029837>