This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: What is the reason to...
>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:
Jifl> Bart Veer wrote:
>>>>>>> "Oliver" == oliver munz @ s p e a g <munz@speag.ch> 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.