From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 19:15:04 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 CA3F516A469; Wed, 2 Jan 2008 19:15:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id A506E13C469; Wed, 2 Jan 2008 19:15:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp003-s [10.150.69.66]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m02JEwmE014259; Wed, 2 Jan 2008 11:14:58 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp003/MantshX 4.0) with ESMTP id m02JEtmV011289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Jan 2008 11:14:56 -0800 (PST) Message-Id: <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> From: Marcel Moolenaar To: John Baldwin In-Reply-To: <200801021303.39518.jhb@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 2 Jan 2008 11:14:55 -0800 References: <20080101.184909.195750479.imp@bsdimp.com> <3FAE3F14-C1B6-41BB-8DB0-A88C1DD09F66@mac.com> <200801021303.39518.jhb@freebsd.org> X-Mailer: Apple Mail (2.915) 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 19:15:04 -0000 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. > 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. 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. 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. 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. 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... -- Marcel Moolenaar xcllnt@mac.com