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 >>>>> that if >>>>> your >>>>> machine gets the COM ports backwards when using ACPI it should >>>>> now get >>>>> them correct (COM1 as sio0) assuming your COM ports use the >>>>> default hints >>>>> and you have the default sio hints in your /boot/device.hints >>>>> file. >>>> >>>> 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 >>> enumerating devices >>> that ACPI/PNPBIOS also dictate, so how does one resolve the >>> differences (do >>> you ignore one or the other, or attempt to merge them, etc.). Note >>> that >>> hints can always be removed. >> >> I think the conflict is resolved by having hints only apply to the >> isa >> bus proper and stop tying apci to the isa bus. This also exposes >> other >> flaws with hints, such as using flags to mark a device as (potential) >> console. > > 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 isn't. > 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. > If you want to move all the > ACPI-enumerated ISA devices under isa0 (which we can do, similar to > how the > ACPI pci(4) driver "claims" the ACPI handles for PCI devices in the > ACPI > 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. >>> FWIW, the resources for COM1 and COM2 are largely fixed in >>> practice on >>> existing x86 hardware which is what this would affect, and hints >>> can always >>> be removed. Given the number of complaints from people where ACPI >>> enumerates >>> 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 >> first >> 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. > Besides, > people also don't like the cosmetics of having ttyd0 being COM2 and > ttyd1 > 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 non-functioning. >>> I've also seen pci link devices where the _UID is the >>> link index from the $PIR table which == the register offset in >>> config space >>> 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 >>> to include >>> default hints for sio0 and sio1. >> >> If the hints would be specific to the ISA bus, then it would >> definitely be >> ok to have them. Even though we don't support i386 hardware, it >> should not >> be a big deal to keep the support for the ISA bus. We should >> really stop >> using acpi as an alias for isa and start treating it as a separate >> "bus". > > See above. ACPI != bus. ACPI == namespace that spans multiple > busses. This > 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... > If you want the configuration file separate from the kernel, then > what do you > consider /boot/device.hints to be? Non-existent. -- Marcel Moolenaar xcllnt_at_mac.comReceived on Fri Oct 12 2007 - 19:18:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:19 UTC