timer functions for non-kernel

[Jani Monoses]

> The driver API was meant to operate even in scenarios where interrupts
> are kept permanently disabled and all I/O happens via polling, e.g.
> RedBoot. It reduces the effort needed inside device drivers to cope

these functions just like the others in drv_api are part of an optional API.
cyg_drv_interrupt , cond_vars , mutexes etc imply interrupts don't they?
what are the disadvantages of adding these functions? Redboot does not use them so it 
cannot be affected.

> Application code is much less likely to suffer from confusion because
> the choice of whether or not to use the kernel usually gets made very
> early in the application design phase.

yes, but the code can be part of a library (my case actually) which would be nice if it 
built against both kernel and non-kernel configs, and to act as boilerplate and framework 
for a yet unknown range of future applications.

> The functions in this patch will only work in scenarios are kept
> enabled most or all of the time, which won't be the case in e.g.
> RedBoot. 

right, I don't want to use them in redboot :). And they're all self-contained and will be 
gc-d at linktime in all current apps.

Otherwise they'll fail silently. I think it is a bad idea to
> have such functions in the system.

I agree it's a bad idea to use them in situations you describe, but I don't yet see why 
having them is a bad idea.
For instance get_current_time() gets the ticks since startup.That is useful regardless if 
a kernel is present or not. Then why not use the same interface and rely on the 
HAL_CLOCK_* functions instead of setting up platform dependent timers by hand?
The fact that a kernel is not used does not mean that apps should be very hw specific; 
after all ecos is useful even as a minimal portable API over a wide range of HALs.

thanks
Jani