From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 18:47:15 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB8C616A4DA; Thu, 3 Aug 2006 18:47:15 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C4943D4C; Thu, 3 Aug 2006 18:47:15 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.150] (pptp0.pn.xcllnt.net [192.168.4.150]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k73Il66G024439; Thu, 3 Aug 2006 11:47:07 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20060803.111243.74675763.imp@bsdimp.com> References: <20060803041522.F2135@epsplex.bde.org> <20060803055353.K635@epsplex.bde.org> <44D151DF.10000@root.org> <20060803.111243.74675763.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 3 Aug 2006 11:46:54 -0700 To: Warner Losh X-Mailer: Apple Mail (2.752.2) Cc: jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, nate@root.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 18:47:15 -0000 On Aug 3, 2006, at 10:12 AM, Warner Losh wrote: > The "minor logic" in newbus is actually kicking my ass right now. I > have stuff in p4 that should implement all the things we need, but the > unit allocation is kicking my butt. I fear that the only real way is > to subclass isa three times: hints-only, pnp+hint-augment, > acpi+hint-augment. In the latter two, how does one tell a 'this hint > is for a card that's there' versus a 'this hint is a wiring hint'? > And for the wiring hints, how much of the device matching do you do? > If the I/O matches, but the IRQ doesn't, is that a match? What about > vice versa? Like I said before: hints are abused for way too many purposes. It's better to come up with a new scheme where you clearly separate the different functions we're looking for and design *as many* different mechanisms to implement these functions. One approach would be to make ACPI unconditional, as it's there to describe the existence of legacy devices and thus serves the same purpose as our current hints and define hints to *only* allow wiring down hardware to unit numbers. These can be called hints because I'm sure we can not always guarantee it. Marking devices as special, like the sio flags is an entirely different function alltogether and should therefore not be done with the same hints. That would just create the convolution, so you create different hints for that. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net