From owner-p4-projects Mon Dec 23 13:17: 0 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 09CDD37B405; Mon, 23 Dec 2002 13:16:57 -0800 (PST) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EF7937B401 for ; Mon, 23 Dec 2002 13:16:56 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3585743EEF for ; Mon, 23 Dec 2002 13:16:55 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gBNLGfrT001627; Mon, 23 Dec 2002 13:16:42 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gBNLHaHF000821; Mon, 23 Dec 2002 13:17:36 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gBNLHaoS000820; Mon, 23 Dec 2002 13:17:36 -0800 (PST) Date: Mon, 23 Dec 2002 13:17:36 -0800 From: Marcel Moolenaar To: "M. Warner Losh" Cc: perforce@freebsd.org Subject: Re: PERFORCE change 22623 for review Message-ID: <20021223211736.GB660@dhcp01.pn.xcllnt.net> References: <20021222231958.GA1414@athlon.pn.xcllnt.net> <20021222.200921.66023382.imp@bsdimp.com> <20021223033542.GA2039@athlon.pn.xcllnt.net> <20021222.233348.122304694.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021222.233348.122304694.imp@bsdimp.com> User-Agent: Mutt/1.5.1i Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 22, 2002 at 11:33:48PM -0700, M. Warner Losh wrote: > In message: <20021223033542.GA2039@athlon.pn.xcllnt.net> > Marcel Moolenaar writes: > : > I just remeber when I did it that it was a big deal to me and to the > : > folks that hired me to create a pci driver for the controller based > : > modems. Maybe things have changed, and if so I'm cool with things > : > going away. But if they haven't changed, this needs to stay around > : > until the underlying problems are fixed. > : > : The console problem has gone now that we only care about the tag > : and handle. The disconnect can still be confusing to people, but > : as I said above, this applies to any device that uses/needs hints. > > OK. As long as the console problem is gone, I'm happy. The hint/unit > disconnect is something that needs to be addressed, but that's a much > uglier issue. This is what I figure: We need to change the semantics of the hints if we want to have consistency. Hints can be given gratuitously now, which decreases their value to the point that they are referenced as a last resort. This includes the PnP case where there are multiple possible settings and as long as there's no conflict either of those settings is equally valid. Hints will help us decide only. Thus, hints are lacking the "authority" to force or dictate behaviour. If we remove the need for hints in cases it isn't required and we stop the gratuity of them being given, we can turn them into reservations. Let's explain with an example: In a machine M are two identical ethernet interfaces, one at address A0 and one at address A1. Bus enumeration has caused the assignment: foo0: at address A1, and foo1: at address A0 Also present in machine M are two serial interfaces of which one is auto-detected (PnP) and placed at address A2. The placement is from the set S={A2,A3,A4} of possible settings. The assignment yields: ser0: at address A2 The second serial interface cannot be found by bus-enumeration and also happens to be hardwired (jumpered) at address A2. The user likes to use that one as the console and wants it given unit 1. Picky as the user is, he also likes foo0 at address A0 and foo1 at address A1. If hints are reservations, the following may possibly achieve what the user wants: foo.0.address=A0 ser.1.address=A2 serial_console=A2 The logic (in chronological order) would be something like: /* {t1,t2}: Make reservations */ t1 Reserve unit 0 of devclass foo for address A0 t2 Reserve unit 1 of devclass ser for address A2 /* {t3}: Console probing */ t3 Probe serial console at address A2; unit unknown /* {t4,t6}: Bus enumeration */ t4 found unreserved foo at address A1; first free unit 1 t5 found reserved foo at address A0; unit 0 t6 found unreserved ser at {A2,A3,A4}; first free unit 0; first free resource A3 /* {t7}: Probe reserved undetected devices */ t7 Undetected reserved ser at address A2; unit 1, console Note that if hints are reservations, the use of unit numbers for console devices is possible, provided a reservation exists that ties it to an address. Thus: serial_console=unit:1 ser.1.address=mem:0x1234 If there's no reservation, serial consoles have to be defined in terms of addresses: serial_console=port:0x3f8 (the prefix "unit", "mem" or "port" is for illustrative purposes) Anyway: just some thoughts... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message