Re: eCos 3.0 beta 1 punch list #2

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes:

    John> eCos Maintainers
    John> The remaining punch list items for eCos 3.0 beta 1 are as follows:

    John> a) Constructor priority re-ordering work. (bartv) [ Thank
    John> you for the check-ins, Bart, is this work complete now?
    John> Please confirm. ]

In theory there is one more change to go in: updating the flash
subsystem to use a prioritized constructor, and associated API
changes. Effectively this would replace explicit calls of
cyg_flash_init() with automatic initialization via a C++ static
constructor. That should simplify higher-level code since there is no
longer any need to worry about whether or not the flash subsystem has
been initialized. It would also give some code size savings in the
flash subsystem, and in the medium to long term it would allow other
subsystems such as fconfig to be statically initialized as well.

However, after experimenting with various different patches, I have
come to the conclusion that this is not the right time to make the
change. It is not too bad when there is only a single flash device and
everything works, but if there are initialization problems then things
get messy. So instead of making the change now, for all anoncvs
targets and with no possiblity of testing on most of those targets, I
want to do the work in eCosPro first. It can then be merged into a
future anoncvs release, once I am confident that it is not going to
break anything.

Referring back to earlier discussions (see ecos-devel 18 Nov 2008):

1) the jffs2/dataflash problems have already been resolved. Flash
   block devices in devtab, initialized at CYG_INIT_IO, will now
   happen after CYG_INIT_BUS_SPI. There is no longer a risk of
   dataflash operations happening before the SPI bus is ready.

2) the specification of cyg_flash_init(), i.e. whether or not it
   takes a printf() function as argument, is not actually important.
   cyg_flash_init() will become deprecated, and mostly a no-op, when
   the flash subsystem switches to using a prioritized constructor.
   It does not actually matter if a deprecated function takes a
   function pointer as argument.

   That means there are no long-term API concerns either. There are
   functions to be added to the API, but those can wait till later.

So, best to leave the anoncvs flash subsystem in its current state for
now. That means I have finished for 3.0.

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.
Besuchen Sie uns vom 3.-5.03.09 auf der Embedded World 2009, Stand 11-300
Visit us at Embedded World 2009, Nürnberg, Germany, 3-5 Mar, Stand 11-300