On 04/10/2019 08:06, Chris Johns wrote:
On 4/10/19 3:10 pm, Sebastian Huber wrote:
On 04/10/2019 04:44, Chris Johns wrote:
Is this only useful for virtual BSPs and is it always a requirement to implement
this call in those environments?
Would this call be useful to a non-virtual BSP, for example one with a battery
backed RTC device?
Would a hook API along the lines of ....
typedef int (*_TOD_Set_Handler)(const struct timespec *tod);
_TOD_Set_Handler _TOD_Set_hook(_TOD_Set_Handler handler);
... be more flexible?
Yes, I think this should be generalized to allow RTC drivers to use this API as
well. I think it should be possible to install (and remove) more than one hook,
e.g.
typedef enum {
TOD_ACTION_SET_CLOCK
} TOD_Action;
Nice.
typedef struct TOD_Hook {
Chain_Node Node;
int (*handler)(struct TOD_Handler *, TOD_Action, const struct timespec *);
} TOD_Hook;
I like the simpler interface of returning the current hook and specifying those
who obtain a hook call the returned hook pointer if it is not NULL. This way we
only need to hold a single pointer and there is no complexity around locking etc
to update a list as the hook holder has to deal with that locally.
We already have _TOD_Lock() which uses a full mutex. If you let the
caller handle the potential chaining, then you may loose events.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
