On Friday, February 26, 2016 11:08:37 PM Warner Losh wrote:
> On Fri, Feb 26, 2016 at 6:49 PM, Marcel Moolenaar <mar...@xcllnt.net> wrote:
> Any reason not to add .disabled=1 to all the entries that are there,
> with the possible exception of uart.0? At least for i386 and amd64?
> Bonus points for writing code that filters those out when there's
> no ACPI. While PNPBIOS could also supply this info, I doubt that you
> could find hardware that has pnpbios data and not ACPI data except
> maybe some of the soekris boxes to test against.
> Better still would be to split the current GENERIC.hints into two bits.
> One that was strictly for legacy (!ACPI and !PNPBIOS) situations, and
> one that we always load. There look to be at least a couple of hints
> that are universally relevant still. I might have a 200MHz pentium I
> can test this with...
If there was an easy way to load a new hints file we could ship a
/boot/legacy.hints and have a note in the handbook / FAQ about using it if
needed. We could even have smarts in the loader to suck it in perhaps if
!ACPI and !PnPBIOS.
> As near as I can tell, only the following are relevant:
hint.sc.0.at is relevant if you want to use sc(4) instead of vt(4). For a
long time I've booted machines that only had that hint. The npx.0 hint used
to matter (but no longer does).
I think we should definitely trim the hints file for amd64. amd64 pretty
much mandates ACPI. For i386 I would be fine with a the legacy.hints route
even if it wasn't automagical but something you had to manually load. The
only thing about the hints that is still somewhat useful on x86 is enabling
serial console (though boot -h and/or console=comconsole already does that)
and enabling remote GDB. (hint.uart.1.flags=0x80 is shorter and doesn't
require remembering random I/O port addresses like the hw.uart route for
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"