From owner-freebsd-embedded@FreeBSD.ORG Tue Jan 1 20:58:57 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48EC416A418; Tue, 1 Jan 2008 20:58:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0340C13C45B; Tue, 1 Jan 2008 20:58:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id m01KwGAv037426; Tue, 1 Jan 2008 13:58:16 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 01 Jan 2008 13:58:25 -0700 (MST) Message-Id: <20080101.135825.1943337000.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> <200712311606.25424.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 20:58:57 -0000 In message: Marcel Moolenaar writes: : Let's just fix this right... In many ways, you are complaining about the same thing that I've struggled with. Sometimes, hint.sio.0.addr=0x3e8 means 'bind whichever of the enumerated COM ports lives at 3e8 to sio0' (eg, cross binding of a device enumerated by other means to a driver/unit) and sometimes it means 'you have a COM port whose resource starts at 0x3e8'. If you have trouble reading the difference between those two statements, it is the difference between binding a known device node (known through looking at an BIOS provided table) and the OS providing that entire table. I disagree with you that it is a fundamental flaw in the system, but am always open to better suggestions at how to implement this stuff. The hints were my first, best guess, and they have served us well. We are at the point now where we must expand them either as John has outlined, or we need to scrap them entirely in favor of something better. What we cannot do is let the promise of something better that isn't really being worked on stop us from expanding what we have. Do you have something specific in mind that we can start working on some kind of design document against? It is OK if that's a series of conversations, but we have to get off the inflection point we're at now: No, you can't expand what's there, and there's no clearly articulated 'something better'. So if you could take a few minutes and write up a straw-man proposal for what you see as doing it right, I think that would get us toward a solution... Warner