On 2013-07-19 00:29, Peter Dufault wrote:
I thread this needle by implementing it both ways. You do sometimes want a
compliant, high-performance, low-memory in-line implementation of (especially)
primitives like mutex locking and semaphores. You also don't want users to
cheat. What I do is (this is a dramatization, I don't really have code with
_RTEMS_HIDE_IMPLEMENTATION):
- Add a feature test macro e.g. _RTEMS_HIDE_IMPLEMENTATION that forces the
implementation to be hidden.
- When that feature test is in effect only global interfaces compliant with the
POSIX spec appear in any header.
- Implement a C language implementation that uses the same implementation that
shows up when _RTEMS_HIDE_IMPLEMENTATION is not defined to provide a linkable
fallback.
When you generate a release you can verify it builds and runs properly with
_RTEMS_HIDE_IMPLEMENTATION for all targets. Anyone using the hidden implementation,
given that it is in the "leading underscore" name space reserved for the OS,
will hopefully either know what they are getting into or will only make the mistake once.
This is mostly what we had with the *.inl files
(__RTEMS_VIOLATE_KERNEL_VISIBILITY__). I see three problems with this approach.
1. This *.inl covered only inline functions. Global functions and internal
type definitions were still exposed.
2. If you change an implementation header file, then you have to re-compile
considerable more files than necessary.
3. You still have to install all the header files.
With the move to the *impl.h files we may consider to not install them. So a
user has to copy the file from the RTEMS source tree to use parts of the
internal implementation.
--
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 : [email protected]
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
