On 04/10/2019 17:08, Joel Sherrill wrote:
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.
The hook infrastructure needs to be testable. Your v1 patch added
untestable code paths non-paravirtualized environments. A generalization
of the API is easy and may be beneficial in the future (e.g. use in RTC
drivers). At the moment I don't see a need for a public API. We can add
a wrapper later if necessary.
--
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
