From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 20:19:08 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 873FE16A477 for ; Wed, 2 Jan 2008 20:19:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 44B6E13C465 for ; Wed, 2 Jan 2008 20:19:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 227051836-1834499 for multiple; Wed, 02 Jan 2008 15:17:00 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m02KIpIc019397; Wed, 2 Jan 2008 15:18:54 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Wed, 2 Jan 2008 14:53:02 -0500 User-Agent: KMail/1.9.6 References: <200801021303.39518.jhb@freebsd.org> <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> In-Reply-To: <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801021453.02931.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, 02 Jan 2008 15:18:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5343/Wed Jan 2 12:41:01 2008 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: 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: Wed, 02 Jan 2008 20:19:08 -0000 On Wednesday 02 January 2008 02:14:55 pm Marcel Moolenaar wrote: > > On Jan 2, 2008, at 10:03 AM, John Baldwin wrote: > > > Agreed, and device.FOO would create an unknownX device (much like > > unprobed > > PNPBIOS or ACPI-enumerated devices) with a set of properties (if the > > bus impl > > uses properties to create devices and doesn't use them purely as > > additional > > metadata). For example, I actually figured that the default > > device.hints type > > stuff for COM1 would look like this: > > > > device.COM1.at="isa" > > device.COM1.port="0x3f8-0x3ff" > > device.COM1.irq=4 > > device.COM1.pnpid="PNP0500" > > BTW: I like the port range. I hate that abuot the current hints actually where drives hardcode things like IO_COMSIZE. I really would like the enumeration data that is provided not by the firmware to look like something that comes from firmware, on which we seem to agree. > > which is what you get with ACPI/PnPBIOS. On i386/amd64 users would > > probably > > wish to bind it using something like: > > > > device.COM1.driver="sio" > > device.COM1.unit=0 > > > > but it wouldn't be required. Note that it would be nice to just > > say 'device.COM1.unit=0' and not specify a driver at all, but that > > would not > > be easy to implement in new-bus. > > It can also cause conflicts. With uart and sio, you can > wire both to the same unit, based on the fact that sio > attaches to legacy devices by default and uart attaches > to puc by default. If you remove the sio driver, then you > end up with 2 wiring directives for the same unit that > now apply to the same driver. Explicitly specifying the > driver+unit makes it clear what is meant: if there are > multiple directives for the same driver+unit, then it's > obvious that the directives are conflicting and thus that > it's pilot error. Yeah. The problem is that in the case of the reversed com ports with ACPI that's all the users really want is the units to be right, they don't really care exactly which driver attaches. In some ways it would be nice if we could just give names to devices and use _UID for that or the node in the namespace (though the latter can fall down if you have an exceptionally lame namespace like my laptop's BIOS (see www.freebsd.org/~jhb/gpe/acpi.nc6220, all non-reserved names in the ACPI tree are Cxxx)) to generate user-visible device names like /dev entries, but I think that something like that might be too much upheaval. Also, I'm not sure it would scale well across different machines. For example, at work we really want the device that is labelled COM1, COMA, Serial A, whatever, to be the serial console and to have a getty running on it. Currently the easiest way for us is to bind sio0 to the resources for COM1 using hints and use /dev/ttyd0. _UID and namespace names are too unreliable for us to use those unfortunately. > Anyway, back to hints: your new approach is not disliked > by me. It fits my concept for the most part. However, in > order to support embedded hardware, we need to extend the > syntax (like using a range for the I/O port). Extending > the syntax may involve some significant work; even to the > extend that we can call it a rewrite, even if we keep > calling it hints. > > More examples: the e500 core can have up to 4 MACs. Each > MAC has 3 interrupts. We need to support this. Also, some > devices have multiple I/O resource ranges. This too needs > to be supported. If we can modify the current hints > slightly to support it than I'm happy. It's just that I > have not seen any consideration for it and could only > assume it would fall through the cracks. Regarding resources, I'd really like to be able to specify RIDs so you could do: device.FOO.irq.0="4" device.FOO.port.1="0xa-0xb" (RID 0 of SYS_RES_IRQ and RID 1 of SYS_RES_IOPORT) I also wonder if it would be nice to isolate I/O resources in their own property namespace. Something like: FOO { resources { irq { 0=4 } ioport { 1=0xa-0xb } } at="blah" } We could also call 'at', 'location' perhaps. > Also, A syntax like: > FOO { > sub1=a > sub2=b > } > > ... can be considered syntactic sugaring, because it > can mean exactly the same as: > FOO.sub1=a > FOO.sub2=b > > This too is exactly like hints. So, even a discussion > about syntax does not mean we need to toss out everything > we have and start from scratch. True. My worry here is making sure we can change it from the loader still. However, I also would still like to have a loader command for managing this in which case having it be in the kernel environment just like hints may be less important. That is, if "device FOO irq.0 4" will work, then we can replace /boot/device.hints with 'device' invocations and the backing-store for passing the data from the loader to the kernel is less important. > The bottomline: I'm not arguing that we cannot end up with > something that looks like hints. I'm arguing that if we > take hints *as they are* and apply your tweaks, that we don't > solve all the problems we're having or know we will have. > > More examples: I think we need to make hints conditional > so that they can be included in case they're needed, but > can be disabled/masked in case they're not (and more > specifically when they're wrong and fry your SoC). Since > hints as we have them today are unconditional, I can only > object to using hints because of the fact they are unconditional > and there's no intention to make them conditional. Well, they are somewhat conditional now (isa(4) at least respects the "disabled" hint). Are you looking for a single "turn all of them off" switch or a per-object disable? > Anyway: I don't mind if you decide to step away from this, > but I do think you're making a mistake in that case. If > anything, it's important that people keep arguing to make > sure that we find the right balance... Well, I'll chew some more. At least this time I don't have any code yet that I'm throwing away. -- John Baldwin