<div dir="ltr">I can't conceive of a use case where you would need more than one hook set.<div>Do you have something in mind?</div><div><br></div><div>The int returned may need to be an enum so there is a list of known failures which</div><div>can be mapped to API specific errors. </div><div><br></div><div>Any ideas on the new API to register with? Whether it is one hook or a set, we will</div><div>need an API. Is this part of the rtems_clock_ APIs? or something like</div><div>rtems_tod_register_hooks() and unregister? I'm having trouble putting a name on </div><div>the API.</div><div><br></div><div>The way I implemented this, it was not called in non-paravirtualized environments and</div><div>required to be provided by the BSP in paravirtualized environments. It was quite</div><div>simple.</div><div><br></div><div>I'm happy to move to a register type interface. Just want help in defining requirements and</div><div>API specifications.</div><div><br></div><div>--joel</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 4, 2019 at 1:25 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 04/10/2019 08:06, Chris Johns wrote:<br>
> On 4/10/19 3:10 pm, Sebastian Huber wrote:<br>
>> On 04/10/2019 04:44, Chris Johns wrote:<br>
>>> Is this only useful for virtual BSPs and is it always a requirement to implement<br>
>>> this call in those environments?<br>
>>><br>
>>> Would this call be useful to a non-virtual BSP, for example one with a battery<br>
>>> backed RTC device?<br>
>>><br>
>>> Would a hook API along the lines of ....<br>
>>><br>
>>> typedef int (*_TOD_Set_Handler)(const struct timespec *tod);<br>
>>>    _TOD_Set_Handler _TOD_Set_hook(_TOD_Set_Handler handler);<br>
>>><br>
>>> ... be more flexible?<br>
>> Yes, I think this should be generalized to allow RTC drivers to use this API as<br>
>> well. I think it should be possible to install (and remove) more than one hook,<br>
>> e.g.<br>
>><br>
>> typedef enum {<br>
>>    TOD_ACTION_SET_CLOCK<br>
>> } TOD_Action;<br>
> Nice.<br>
> <br>
>> typedef struct TOD_Hook {<br>
>>    Chain_Node Node;<br>
>>    int (*handler)(struct TOD_Handler *, TOD_Action, const struct timespec *);<br>
>> } TOD_Hook;<br>
> I like the simpler interface of returning the current hook and specifying those<br>
> who obtain a hook call the returned hook pointer if it is not NULL. This way we<br>
> only need to hold a single pointer and there is no complexity around locking etc<br>
> to update a list as the hook holder has to deal with that locally.<br>
<br>
We already have _TOD_Lock() which uses a full mutex. If you let the <br>
caller handle the potential chaining, then you may loose events.<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div>