Re: New-bus unit wiring via hints..
- From: John Baldwin <jhb@xxxxxxxxxxx>
- Date: Mon, 15 Oct 2007 12:16:36 -0400
On Friday 12 October 2007 05:17:51 pm Marcel Moolenaar wrote:
On Oct 12, 2007, at 1:20 PM, John Baldwin wrote:
On Friday 12 October 2007 03:49:28 pm Marcel Moolenaar wrote:
On Oct 12, 2007, at 11:09 AM, John Baldwin wrote:
On Thursday 11 October 2007 05:59:23 pm Marcel Moolenaar wrote:
On Oct 11, 2007, at 2:41 PM, John Baldwin wrote:
2) One of the things this fixes that is visible to users is
machine gets the COM ports backwards when using ACPI it should
them correct (COM1 as sio0) assuming your COM ports use the
and you have the default sio hints in your /boot/device.hints
I think you just pointed out the problem of using hints to wire
down unit numbers, because hints will stop hinting and will start
dictating. If I swap the serial ports in the BIOS then surely
my hints will be wrong and ACPI will be right. A default hints
file will be even more disastrous than before.
hints have always dictated. The issue is that hints are
that ACPI/PNPBIOS also dictate, so how does one resolve the
you ignore one or the other, or attempt to merge them, etc.). Note
hints can always be removed.
I think the conflict is resolved by having hints only apply to the
bus proper and stop tying apci to the isa bus. This also exposes
flaws with hints, such as using flags to mark a device as (potential)
The issue here is that the 16550 UART that ACPI enumerates is on
the LPC bus,
that is, it's an ISA device.
LPC mimics or replaces ISA. I don't treat them the same. For one, ISA
has actual slots to plug in extension cards. LPC is enumerated. ISA
Do you think we should scrap the PCI bus driver we have and make a PCI-e bus
driver because PCI-e just mimics or replaces PCI?
In this case, ACPI is subsuming the role of the
PNPBIOS to enumerate ISA devices.
This is a PC notion. There's no PNPBIOS on ia64 for example. There is
ACPI that enumerates devices on the LPC bus though.
This is in the spec. Check the introduction on page 1 of the ACPI 3.0a
specification. It is a "configuration interface", not a bus specification.
As far as ia64, just don't include hints for sio0 on ia64. Shoot, ia64 uses
uart(4) rather than sio(4) anyway, right? On the "PC" architectures, COM1
and COM2 are a de-facto standard, so on those platforms it makes sense to
have sio0 and sio1 hints. This patch does not _mandate_ hints at all.
However, while ia64 may be able to count on having all its devices nicely
enumerated for it one way or another, the x86 platform does not. :(
You also ignore that other platforms like arm use hints to enumerate devices
on "dumb" busses.
If you want to move all the
ACPI-enumerated ISA devices under isa0 (which we can do, similar to
ACPI pci(4) driver "claims" the ACPI handles for PCI devices in the
namespace) we can do that, but that doesn't solve the problem at all.
Hell no. That's exactly what I don't want. The isa(4) bus with its
devices should be obsoleted entirely.
Just because there isn't a slot doesn't mean it isn't there. If a future
system only has PCI devices in embedded chips and only has PCI-e slots does
that mean we need to throw out the pci(4) bus driver or force the embedded
PCI devices to live under a different driver?
FWIW, the resources for COM1 and COM2 are largely fixed in
existing x86 hardware which is what this would affect, and hints
be removed. Given the number of complaints from people where ACPI
COM2 before COM1 (and the fact that ACPI made _UID useless by not
giving it a
more strict format.. it's optional and on some systems it is 0-
based while on
others it is 1-based.
But aren't the complaints the immediate result of having hints in the
place. Remove the hints and the complaints go away, right?
No. The kernel console switches because it is bound via hints.
More hints, more problems. As I said before: it's a mistake to use
hints for that because it makes hints ambiguous.
I disagree. I don't really see how this makes hints ambiguous. If anything,
it makes them _less_ ambiguous. Previously you would have hints for a sio0
at resource X and a sio device at resource Y used some of the sio0 hints if
sio0 was probed via ACPI. At work we actually disable the ACPI attachment
for sio and always attach it via isa precisely due to this conflict. With
this change, hints now always mean something as opposed to meaning different
things on x86 depending on whether or not ACPI is used.
people also don't like the cosmetics of having ttyd0 being COM2 and
being COM1, etc.
More legacy PC fixation. If the BIOS claims that COM1 is at 0x2f8 then
so be it. If COM2 is enumerated first and it ends up as uart0 then so be
it. There's no bug. It's all in a name. Device wiring would allow people
to tie COM2 to uart1 if they want to, but all this COM-stuff is really
nothing more than a fixation on 20-year old conventions that the rest
of the world abandoned many years ago. It's turned into a bigger problem
than it really is, mostly because we still have those stupid hints that
are based on 20-year old conventions.
ACPI describes the hardware and FreeBSD should respect that. I consider
it mere coincidence that there's a serial port at I/O port 0x3f8 that
ends up as sio0 on most current PCs. If ACPI describes a different
hardware configuration then I don't think that we're in any position to
claim that ACPI is wrong or the hardware broken. We can only claim that
IFF there's no hardware at those resources or the hardware is in fact
Sadly, this ignores the fact that much of the PC "standard" is de-facto, not a
written standard. Having COM1 (or serial A or however it's labeled on the
case) being at 0x3f8 with an IRQ 4 is a de-facto standard. Note how our boot
code hardcodes the I/O port address for the serial console
(BOOT_COMCONSOLE_PORT). At work we have a lot of different machines from
many different vendors and having that hardcoded as the default has worked
fine. It truly is a de-facto standard for the PC, just as having the
keyboard at 0x60, the PICs at 0x20 and 0xa0, etc.
I've also seen pci link devices where the _UID is the
link index from the $PIR table which == the register offset in
on the PCI-ISA bridge of the controlling register) and the fact
that COM1 and
COM2 have de-facto fixed resources on x86, I think it's ok for x86
default hints for sio0 and sio1.
If the hints would be specific to the ISA bus, then it would
ok to have them. Even though we don't support i386 hardware, it
be a big deal to keep the support for the ISA bus. We should
using acpi as an alias for isa and start treating it as a separate
See above. ACPI != bus. ACPI == namespace that spans multiple
is an important distinction.
Drivers need a bus attachment to work with ACPI, so we have abstracted
it as a bus. Therefore, it's a bus in FreeBSD. The abstraction is good.
I don't see a problem with it...
We do have to have a bus because not all devices it enumerates are LPC devices
(and it isn't even consistent in that sometimes the embedded controller and
PCI link devices are under _SB_ and sometimes they are under the LPC bus),
and I actually don't mind the arrangement we have now (moving ISA devices
around was a suggestion above to try and satisfy your requirements, I think
it's more headache than its worth). However, ACPI is not just a simple bus
spec, it is a configuration interface that includes a namespace that spans
lots of busses. One of its stated tasks (again, see the introduction on page
1 of the ACPI spec) is to help fill in the holes in the hacked-up PC/x86
platform by trying to subsume lots of different one-offs ($PIR, MPTable,
PNPBIOS, APM, etc.) into one interface.
If you want the configuration file separate from the kernel, then
what do you
consider /boot/device.hints to be?
Ok, let's try this again. You said you want a configuration file separate
from the kernel. We have one now in the form of /boot/device.hints. It sets
a configuration in the form of environment variables that can be easily
manipulated from the loader and that is independent of the kernel, but is
instead a description of a machine. We already set lots of other things via
environment variables to configure the kernel as well (loader tunables like
kern.maxfiles, etc.), so it seems rather consistent to use environment
variables for configuring the device support that the kernel can't auto-learn
from the hardware/firmware. What do you want different? Do you want it in
XML? Do you want it not maintainable from the loader?
freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Re: New-bus unit wiring via hints..
- From: Marcel Moolenaar
- Re: New-bus unit wiring via hints..
- Prev by Date: Re: panic: ffs_blkfree: freeing free block
- Next by Date: Re: panic: ffs_blkfree: freeing free block
- Previous by thread: Re: New-bus unit wiring via hints..
- Next by thread: Re: New-bus unit wiring via hints..