[PATCH 5/9] posix: Convert to inline function
Sebastian Huber
sebastian.huber at embedded-brains.de
Fri Jul 19 07:13:51 UTC 2013
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 : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list