From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24849 invoked by alias); 18 Nov 2008 18:39:06 -0000 Received: (qmail 24788 invoked by uid 22791); 18 Nov 2008 18:39:05 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Nov 2008 18:38:15 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E33C021800C for ; Tue, 18 Nov 2008 18:38:12 +0000 (GMT) X-Virus-Scanned: amavisd-new at ecoscentric.com Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoTsRj8s46b1; Tue, 18 Nov 2008 18:38:11 +0000 (GMT) Received: from delenn.bartv.net (hagrid.vpn.ecoscentric.com [192.168.145.1]) by mail.ecoscentric.com (Postfix) with ESMTP id A4F463B40069; Tue, 18 Nov 2008 18:38:11 +0000 (GMT) Date: Tue, 18 Nov 2008 18:39:00 -0000 Message-Id: From: Bart Veer To: Jonathan Larmour CC: ecos-devel@sourceware.org In-reply-to: <4922F829.3070507@eCosCentric.com> (message from Jonathan Larmour on Tue, 18 Nov 2008 17:15:21 +0000) Subject: Re: What is the reason to... References: <4910602A.3090408@speag.ch> <4922F829.3070507@eCosCentric.com> Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2008-11/txt/msg00032.txt.bz2 >>>>> "Jifl" == Jonathan Larmour writes: Jifl> Bart Veer wrote: >>>>>>> "Oliver" == oliver munz @ s p e a g writes: >> Oliver> mark CYGPKG_IO_SPI as HARDWARE? Oliver> I think Generic SPI or I2C and so one should be loadable Oliver> whitout an template. Can we change this? >> >> The problem here is that other drivers such as the wallclock or >> dataflash are likely to depend on the SPI/I2C bus being >> available. On some platforms there may even be platform HAL >> dependencies on the bus. Now, by convention you can enable >> flash support on a given platform simply by e.g. "ecosconfig >> add flash" and everything sorts itself out. If the SPI or I2C >> bus driver was not automatically part of the configuration then >> that would stop working. >> >> If you want the SPI or I2C support to be automatically >> available when needed, working within the limitations of >> current CDL, then the generic SPI or I2C packages have to be >> part of the target definition in ecos.db. That means they have >> to be hardware packages. Jifl> I've said this before and will just take the opportunity to Jifl> say it again: the 'hardware' attribute just gets in the way. Jifl> You can't have packages in the target definition that aren't Jifl> 'hardware', and you can't add packages which are marked as Jifl> 'hardware', so there is a wholly artificial division between Jifl> packages. Jifl> I would prefer the whole 'hardware' attribute was dropped Jifl> and give platform developers, and application developers the Jifl> ability to control their own hardware configuration without Jifl> having to edit repository files. It should be possible for Jifl> the HAL developers to list any driver packages appropriate Jifl> for their hardware in the target definition; and possible Jifl> for app developers to add/remove from that as needed. Jifl> There's always been plug-in modules, expansion buses etc., Jifl> nevermind modern configurable hardware, so assuming hardware Jifl> is static seems archaic. Jifl> I suspect it has cost people more wasted time and confusion Jifl> than it has ever saved. I've had to jump through these Jifl> hoops, and not seen any benefit. The hardware attribute is an extremely poor substitute for what I had planned in the original design of the configuration system, but in my opinion right now is not the right time to have that discussion. The SPI and I2C subsystems work just fine when developers follow the documentation, although admittedly it would have been useful if there had been reference driver implementations checked in at the same time as the generic packages. AFAIK nobody is planning any further work on the host-side tools before 3.0, so the hardware attribute will stay for the foreseeable future. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071.