Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Jan 2009 15:40:30 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        arch@freebsd.org, gad@freebsd.org
Subject:   Re: Trimming the default /boot/device.hints
Message-ID:  <200901281540.30546.jhb@freebsd.org>
In-Reply-To: <20090128.122411.1626285557.imp@bsdimp.com>
References:  <200901260947.32870.jhb@freebsd.org> <p06240807c5a64df6e188@[128.113.24.47]> <20090128.122411.1626285557.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote:
> In message: <p06240807c5a64df6e188@[128.113.24.47]>
>             Garance A Drosehn <gad@FreeBSD.org> writes:
> : At 11:39 PM -0700 1/27/09, M. Warner Losh wrote:
> : >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.
> : 
> : Admittedly I know almost nothing about the hints themselves, but I
> : like this idea.  We already supply multiple kernel files, even though
> : everything is documented in NOTES.  We do it because it's convenient
> : and it costs us nothing.
> : 
> : We could even install the LEGACY.hints file as /boot/legacy.hints,
> : and then if someone has a problem we can say  "go into the boot
> : loader, and type 'include /boot/legacy.hints'.  If that doesn't
> : solve your problem, then your problem is not related to this big
> : change to /boot/device.hints".  And if it *does* solve their problem,
> : they can just look at 'dmesg' after they boot up, and get a good idea
> : of what lines they need to add to /boot/device.hints.
> : 
> : I don't see how this would cost us much (compared to *not* having a
> : legacy.hints file), and yet it might make things much easier if it
> : turns out that too many hints had been removed.
> 
> Actually, that's a very clever idea you've stumbled into.  The boot
> loader already know if acpi is involved, and could trivially be
> augmented to know if there's PNP data.  If neither of them are in
> place, it could automatically load legacy.hints...
> 
> But the cheap 'get the file there' is a good idea.

What I'm worried about I guess is how long we have to maintain this.  Also, 
why do we have hints for ed0 but not ex0?  That is, the current list is 
rather arbitrary and only caters to certain rare hardware and not to other 
rare hardware.  I'd rather just do a simple clean break and drop all of the 
rare hardware.  I don't really think there will be anyone who actually 
_needs_ to include /boot/legacy.hints, but we will be stuck with this very 
arbitrary file forever.

Also, none of the hints I'm proposing to remove are relevant to the 
non-PnPBIOS case.  They are all devices that the PnPBIOS would not enumerate 
anyway.

The PnPBIOS related hints are an entirely separate ball of wax from ISA NICs.  
For the PnPBIOS case I could possibly see the case for a legacy.hints (though 
I'd rather have an x86 isa0 driver that added suitable devices explicitly if 
there was no ACPI or PnPBIOS), but the primary motivation for the recent 
changes to the hints code was to allow for the graceful coexistence of those 
hints with ACPI and PnPBIOS.  That is, it should be perfectly fine to use 
that sort of legacy.hints by default, and not require the users to manually 
load it for the non-(ACPI or PnPBIOS) case.  In that case, legacy.hints 
basically degenerates back into device.hints, which is basically what I 
proposed at the very beginning.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901281540.30546.jhb>