I can't conceive of a use case where you would need more than one hook set.
Do you have something in mind?
The int returned may need to be an enum so there is a list of known
failures which
can be mapped to API specific errors.
Any ideas on the new API to register with? Whether it is one hook or a set,
we will
need an API. Is this part of the rtems_clock_ APIs? or something like
rtems_tod_register_hooks() and unregister? I'm having trouble putting a
name on
the API.
The way I implemented this, it was not called in non-paravirtualized
environments and
required to be provided by the BSP in paravirtualized environments. It was
quite
simple.
I'm happy to move to a register type interface. Just want help in
defining requirements and
API specifications.
--joel
On Fri, Oct 4, 2019 at 1:25 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> 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
