This is the mail archive of the ecos-patches@sources.redhat.com 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: timer functions for non-kernel



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



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