This causes these hints to be only used to wire device unit numbers
for serial ports enumerated by ACPI but will not create ISA device
nodes if ACPI doesn't enumerate them.
PR: 270707
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Can we do this for all the other devices?
and
Do we need the IRQs still?
Basically, I'd like to move way away from these hints as a 'fallback' since we don't really support booting anymore w/o a device enumerator (even for the ISAPNP case for old-old-old-school x86). I'm completely cool dropping support for all environments that don't enumerate devices properly.
So I like the idea of removing everything but the last two lines, with the possible exception of the two uarts, which will just become "acpi" and an port. Flags has become OBE largely, I think, though the boot loader console code uses it as a fallback (well, UEFI needs to include ACPI in it to get it completely right).
also, you need to update i386 too hints I think.
Comment Actions
I was going for a minimal change to start. I think for i386 we should leave things alone as i386 can still boot on hardware without ACPI or PnPBIOS in theory (we have not in fact removed support for all that stuff, and you can boot an i386 kernel without ACPI or APIC enabled in bhyve just fine). The IRQs for devices using only "acpi" for the bus probably can be removed. I have a followup to remove other devices that aren't "always there" (that you've already approved) which is why I only changed the UART devices in this review. The remaining "isa" devices after both changes (atrtc, attimer, and atkbdc) are always present. Also, this PR is about the serial ports, so I wanted to keep this change specific to those.
Comment Actions
And yes, I think flags for uart0 probably needs to stick around still to support BIOS booting which isn't quite dead yet.
Comment Actions
How? I think it's only used as a fallback, and not by the boot loader at all. The boot loader designates the serial console differently since marcel's uart rewrite a decade ago. /boot/loader always sets hw.uart.console, for both EFI and BIOS.
Comment Actions
Interesting. I'd still kill it there. Though we're killing the whole thing, so removing it entirely like that is fine. :). Also, i386 systems aren't the problem, except new amd64 systems people run as i386 kernels. There, they can edit device.hints if they are on a newish system. Or we can severely prune it and give them a legacy file. We've already pruned the device.hints so there's going to be issues with at least some of the devices. It comes down to how far back into the past we want to support, and how many people we cater to (like bhyve w/o PNPBIOS even) vs how many people are affected (though very few people run i386 kernels on their 64-bit laptops on latter-day 64-bit machines (all those with > 4GB of RAM).
The IRQs for devices using only "acpi" for the bus probably can be removed.
It's not used for wiring.
I have a followup to remove other devices that aren't "always there" (that you've already approved) which is why I only changed the UART devices in this review. The remaining "isa" devices after both changes (atrtc, attimer, and atkbdc) are always present. Also, this PR is about the serial ports, so I wanted to keep this change specific to those.
I think that takes a too narrow view. All these devices we assume are there are screwed up somewhere. We need to also remove keyboard fallbacks for other laptops, for example. It's a general problem, and we should look at a general solution. This is one instance of the "we bogusly assume things are always there when they are not).
Especially atkbdc because it's not always there, and at times even when it is, the emulation is so poor as to cause problems because windows hasn't used it in a while... I've had a number of bugs that I've fixed there related to this that I think would go away since we support the newer interfaces well now... At the very least, we should only create it when they are in acpi as well. But for atkbdc, we don't need to wire the unit number: nobody cares and even if it's wrong, all things downstream from it are right. Even the A20 line stuff for related to the ports that atkbdc manages isn't, per se, part of atkbdc driver...
attimer and atrtc should be killed here: if they aren't in ACPI, we shouldn't mess with them. For old systems that get it wrong, we should document what to do. I worry that in the future as gates continue to be optimized away, these will also cause problems and we're better off removing as much as we possibly can to boot on systems made in the last 10 or 15 years. The early systems with ACPI issues in this area are > 20 years old at this point as far as I recall, though I wasn't paying attention that whole time.
Comment Actions
Still think we can drop the flags, since they are just used for fallbacks for ancient boot loaders (FreeBSD 9), but this is better...
And we can likely drop others (it's the same problem that's at the root of 270707), but I've made my point and will just drop the ones I know are problematic for legacy free hardware in a separate commit.