Trimming the default /boot/device.hints

[M. Warner Losh]

In message: <200901280930.50727.jhb at freebsd.org>
            John Baldwin <jhb at freebsd.org> writes:
: On Wednesday 28 January 2009 1:39:03 am M. Warner Losh wrote:
: > In message: <200901260947.32870.jhb at freebsd.org>
: >             John Baldwin <jhb at freebsd.org> writes:
: > : After the changes to make hints always reserve device names, soem folks ran 
: > : into issues with devices changing names due to previously unused hints now 
: > : always being honored (e.g. hints for non-existent ISA le(4) cards always 
: > : reserving le0).  What I would like to do to help minimize this further is to 
: > : trim the default set of hints.  The number of machines that will run 8.0 that 
: > : have ISA slots is incredibly small, probably zero.  To that end, I would like 
: > : to remove all hints for ISA adapters from i386 and amd64 (amd64 already has 
: > : most of them removed).  Also, the hint for vga0 is not needed as the vga_isa 
: > : driver uses an identify routine to always add itself.  Note that end-users 
: > : can always add hints back later if desired/needed.  However, changing the 
: > : defaults means that some hardware may no longer work out of the box.  My 
: > : guess though is that the set of such hardware is the empty set.
: > 
: > Your guess likely would be incorrect.  There's still a number of
: > embedded machines that have pc-104 busses attached to them.  However,
: > the set is getting much smaller...
: 
: Yes, but do any of those devices have 'adv0', 'bt0', 'aha0', 'aic0', 'ed0',
: 'cs0', 'sn0', 'ie0', 'fe0', or 'le0' on the PC-104 bus?  If not, then the
: set remains empty.  I'm not removing support for ISA devices.  I'm removing
: hints for a specific set of ISA add-on cards.

Right, PC-104 is ISA and has the same devices.  And the cards
connected typically aren't those drivers, but can be (esp ed0 or cs0).
Many older SBCs have these wired into the isa bus w/o the need for an
external card.  These are unlikely to run 8 well, and more modern
cards with PC-104 bus have all the basics on the PCI bus.  My comment
wasn't meant as a "don't do it" but rather a note that the embedded
world significantly lags the desktop/server/laptop market.

: > : If we wanted, we could go further and assume that all machines have either 
: > : PnPBIOS or ACPI and remove most of the other hints as well.  We already sort 
: > : of assume that on amd64 (which has no atrtc0 hints, but still has hints for 
: > : fdc0, ppc0, and some other devices).
: > 
: > A pure PNPBIOS enumerated system is almost working today.  It works on
: > x86 most of the time.  I've run systems that had only minimal hints
: > for sio2 and sio3 and a couple of other minor variants.
: 
: Yes, many of my machines also work fine with only a syscons hint.  The issue
: is if we still want to support machines that have neither ACPI nor PnPBIOS
: (or where someone has to disable both) out of the box.

We can't have it both ways easily.  I think we need to have a more
complete file that matches the drivers that are in GENERIC, even if we
don't turn them all on by default.  I'm cool with having such people
have to copy over additional files to make them work.  Such machines
are going to be very rare, since it is impossible to turn off PnPBIOS
tables in the BIOS, and it has been present since the 486 era of
machines at least (don't have any 386s to check).  PNPBIOS tends to be
used in the embedded world a lot since there's a bigger variety of
BIOSes that are present there due to cost issues...

: > : Here is the proposed diff:
: > 
: > I don't like this change.  However, you've hit on part of the reason I
: > don't like the change.  I don't think it goes far enough, and at the
: > same time loses valuable history.
: > 
: > To address the latter, I'd do a cp GENERIC.hints LEGACY.hints and add
: > comments to the top that this is for systems that don't have PNPBIOS
: > or ACPI or that there's problems with those.
: 
: These are already present in /sys/<arch>/conf/NOTES.  We already have all
: the various historical hints already documented there.  The real issue is
: what set of hints we will include in the default set to support hardware
: out of the box.  The reason I have not gone further and assumed PnPBIOS
: or ACPI is that it is a separate question, and I'd rather do this in stages.

I still think it would be a good idea to have them all in an
easy-to-deploy file that people can copy to /boot/device.hints.

: > To address the former, I'd propose something more like:
: > 
: > hint.fd.0.at="fdc0"
: > hint.fd.0.drive="0"
: > hint.fd.1.at="fdc0"
: > hint.fd.1.drive="1"
: > hint.atkbd.0.at="atkbdc"
: > hint.psm.0.at="atkbdc"
: > hint.sc.0.at="isa"
: > hint.sc.0.flags="0x100"
: > hint.uart.0.port="0x3F8"
: > hint.uart.0.flags="0x10"
: > hint.uart.1.port="0x2F8"
: > 
: > Not sure that the 'sc' lines are needed, but I was too chicken to try
: > without them.  They used to be needed...  The above wires up
: > everything that isn't on the ISA bus, and gives hints that uart0
: > should be the one at 0x3f8, etc.
: 
: I think the fd lines are very much not needed since fdc can enumerate floppy
: drives on its own.  The rest of the hints don't actually work aside from
: sc0 as hints require an 'at' hint before they wire anything.  The sc0 hints
: are still required, though it would be nice to fix syscons to not need a hint
: and just always add a device in an identify routine instead.

I know that on my PNPBIOS enumerated embedded board that the fdc
driver didn't add the fd devices without those lines as recently as
6.2.  To be honest, I've not tested it recently since I haven't booted
FreeBSD on a system with a floppy in quite some time.  Code inspection
suggests that they are still needed:
	/*
	 * Probe and attach any children.  We should probably detect
	 * devices from the BIOS unless overridden.
	 */
	name = device_get_nameunit(dev);
	i = 0;
	while ((resource_find_match(&i, &dname, &dunit, "at", name)) == 0) {
		resource_int_value(dname, dunit, "drive", &dunit);
		fdc_add_child(dev, dname, dunit);
	}


We should add back in the 'at' isa lines for uart 0 and 1 to my list
then to make wiring work.

I'm neutral on the identify routine approach.  In general, we
shouldn't have that.  Instead, shouldn't sc match some PNP device and
attach to that only when the VGA hardware is actually present?  I ran
into problems on really low-end boards that had no VGA hardware, but I
can't recall the details at the moment.  Soekris boards are the most
widely available in this class, although there are others.

hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.fd.1.at="fdc0"
hint.fd.1.drive="1"
hint.atkbd.0.at="atkbdc"
hint.psm.0.at="atkbdc"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.1.at="isa"
hint.uart.1.port="0x2F8"

Warner