From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 22:20:52 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10BD510656DF; Wed, 28 Jan 2009 22:20:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BE4318FC12; Wed, 28 Jan 2009 22:20:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3236E46B49; Wed, 28 Jan 2009 17:20:51 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0SMKjQd000441; Wed, 28 Jan 2009 17:20:45 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Wed, 28 Jan 2009 17:20:40 -0500 User-Agent: KMail/1.9.7 References: <200901281540.30546.jhb@freebsd.org> <20090128.144307.-1398303613.imp@bsdimp.com> In-Reply-To: <20090128.144307.-1398303613.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901281720.40491.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 28 Jan 2009 17:20:45 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8915/Wed Jan 28 14:49:32 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, gad@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 22:20:53 -0000 On Wednesday 28 January 2009 4:43:07 pm M. Warner Losh wrote: > In message: <200901281540.30546.jhb@freebsd.org> > John Baldwin writes: > : On Wednesday 28 January 2009 2:24:11 pm M. Warner Losh wrote: > : > In message: > : > Garance A Drosehn 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. > > Forever. Ah, yes, that is what I'd like to avoid. :( > : Also, why do we have hints for ed0 but not ex0? > > ex0 has an identify routine, and ed0 doesn't. fe0 doesn't have an identify routine nor hints in the default set. We don't ship hints for sound blaster ISA cards by default either not all of which are PnP (mine wasn't). The point being that the set of ISA adapters with hints in the current device.hints is an arbitrary subset. > : 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. > > Why does it matter that we have to keep this around forever? Why not > clean up the drivers from GENERIC then? It seems like we're only > solving part of the problem... The motivation for cleaning up hints is that our default set of hints has resulted in extra fallout for other folks in combination with my hint-wiring changes which I only committed after several people asked me to commit them. To that end, I am simply trying to engage in the smallest possible change that is also self-consistent. Dropping all non-PnPBIOS/ACPI hints seems to fit that bill. > : 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. > > Not necessarily. Many of them would be enumerated for built-in > devices (as opposed to ISA add-in cards). PNP devices are not PNPBIOS devices. No BIOS is going to have an ed0 device or ie0 device in the PNPBIOS table or ACPI namespace. > : 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. > > The problem is that we still need to have a minimal device.hints for > things like the atkbdc and fdc, plus the hack for uart. That's why I > suggested copying the current device.hints to legacy.hints (maybe > augmenting it to be more real) and then slashing device.hints to the > bone. These are all devices that I count as PNPBIOS devices. I can put back the fd0 and fd1 hints, but the rest of the devices being removed are all non-PNPBIOS devices. To me at least there is a distinction. -- John Baldwin