From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 21:29:55 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 68F5916A4DD; Thu, 3 Aug 2006 21:29:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC0B343D46; Thu, 3 Aug 2006 21:29:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k73LSG5i082659; Thu, 3 Aug 2006 15:28:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 03 Aug 2006 15:28:16 -0600 (MDT) Message-Id: <20060803.152816.112545225.imp@bsdimp.com> To: marcel@xcllnt.net From: Warner Losh In-Reply-To: <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> References: <44D151DF.10000@root.org> <20060803.111243.74675763.imp@bsdimp.com> <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 03 Aug 2006 15:28:17 -0600 (MDT) 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 21:29:55 -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. The only thing that's not well suited for hints is the 'what is my console' function. The others can be made to work well with only a few engineering compromises :-). I'll agree that the flags in sio used to specify which UNIT is the console is lame and should be replaced with a generalization of the uart method. > 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. ACPI unconditional can't happen. There are many machines being made today that simply do not implement ACPI. I have several boards at work that implement PNPBIOS, but don't implement ACPI. These are boards that are brand new. I think ACPI is an extra cost option, but I might be confusing things. We do need to deal with cases like this because they are common enough that we'll alienate folks embedding FreeBSD if we take such a course. > 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. Agreed. However, the sio flags to designate a unit as console is the only thing that doesn't fit well with hints, as presently implemented. It should really be something like: console.type={serial,video} console.location= so that would could use a video card not mapped to the default address as the console, etc. It would be up to the driver at attach time to look at the available console meta-information to see if this driver matches that information. Then it wouldn't matter for a serial console point of view what driver unit is assigned. It might matter for other reasons... Warner