This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]