This is the mail archive of the 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: eCos 3.0 beta 1 punch list #2

>>>>> "Jifl" == Jonathan Larmour <> writes:

    >> 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.

    Jifl> Why can it not be in both? Why should eCosPro be special
    Jifl> with respect to a changing API? And incompatible.

Switching the flash subsystem to initialize via static constructors
means that the h/w init order changes for every platform that uses
RedBoot, and very possibly some of the remaining platforms as well.
Currently flash initialization happens after cyg_start() has started
running. All static constructors have already run. Virtual vectors
have been sorted out. The memory map has been sorted via
HAL_MEM_REAL_REGION_TOP() if necessary. Any bist() self-test code has
run. Some other RedBoot init code may have run as well.

Switching to a static constructor means that the flash initialization
will now happen much earlier, before cyg_start(). Now, it is likely
that on most platforms that won't cause any problems - it worked fine
on the platform I tried. But we may easily have overlooked some
dependency somewhere which means that other platforms will stop
working, so that if anybody decides to rebuild and install RedBoot
after 3.0 they'll end up with a brick.

Rolling out this change in anoncvs means that it will affect every
single target in one fell swoop. Rolling it out in eCosPro means that
we get to test the new code one or a small number of ports at a time,
as we do new ports. Typically we'll make very sure that we have a way
of unbricking any board we are porting to, before we start messing
about with the flash. So if there are problems with the new code, we
can find them and fix them prior to any eCosPro release, with no risk
of affecting either our customers or anoncvs users. Over a period of
time the new code will be run on a variety of hardware with different
flash setups.

What I am proposing is pretty much the same strategy that was adopted
for the flash V2 work. That did not immediately go into the anoncvs
trunk because it was considered too dangerous a change. Instead it
went into a separate branch, for those anoncvs users wanting the new
functionality, and it went into eCosPro. Partly due to the latter, by
now flash V2 has been used on sufficiently many different targets that
we believe there is very little risk of it breaking the world for
typical anoncvs users, so the code has been merged into the trunk.

Now, for most application developers this is a storm in a teacup. It
really does not matter all that much whether the flash
auto-initializes or whether they need to make an extra init call from
inside their application.

So, we have a change that offers very little benefit to users, which
significantly changes the order in which nearly all targets
initialize, which may cause some number of targets to break and leave
users with bricks, being put into the source tree very close to
release after not very much testing. The more I worked on this, the
more I realized this was a really bad idea.

>>>>> "Jifl" == Jonathan Larmour <> writes:

    Jifl> externC cyg_flash_printf *cyg_flash_set_printf( const cyg_flashaddr_t 
    Jifl> base, cyg_flash_printf *pf);

    Jifl> which associates the printf function of flash at base 'base'
    Jifl> with function 'pf', returning its previous setting. There
    Jifl> would also be: #define CYG_FLASH_SET_PRINTF_ALL
    Jifl> ((cyg_flashaddr_t)-1);

    Jifl> which is used to set all devices' printf functions (and
    Jifl> always return NULL).

    Jifl> We can instantly deprecate use of cyg_flash_init with
    Jifl> non-NULL argument. And if the messiness is too much to deal
    Jifl> with after all, we can continue with cyg_flash_init, and in
    Jifl> future it would be more or less #defined to
    Jifl> cyg_flash_set_printf.

The discussion on all this back in November involved an incompatible
API change, changing cyg_flash_init() so that it no longer took any
arguments. That meant we had to add new functions for setting the
printf function, e.g. cyg_flash_set_global_printf() and

Now, there are no longer any plans to change the prototype of
cyg_flash_init(). It will continue to take a printf function, and act
as cyg_flash_set_global_printf(). However we'll probably want to mark
it as deprecated to make sure that people are aware things are done a
bit differently than before.

Since for 3.0 it will still be necessary for applications to call
cyg_flash_init(), and since cyg_flash_init() still takes a printf
pointer, there is very little point in implementing the set_printf()
functions right now. It would only affect application code that
currently calls cyg_flash_init() multiple times with different
arguments, to change the printf function at run-time. I suspect that
very few applications do that. If they do then in future they'll get
multiple compile-time warnings about cyg_flash_init() being
deprecated, as opposed to just a single warning about cyg_flash_init()
and no warnings about the cyg_flash_set_global_printf() calls.

So, a change that is likely to benefit very few users, and negligible
future harm if we leave the API as it is right now. Again, the
most sensible thing to do is to leave things as they are and come back
to this after the release.


Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts
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

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