On Thu, 2008-07-17 at 15:13 -0400, Jonathan S. Shapiro wrote:
> All of that being said, the Coyotos kernel (so far as I can remember)
> doesn't have any conditional compilation that can't be resolved by
> playing with interface paths.
I'm guessing you can always do that, but it may be at the cost of
clarity and/or code duplication (if only duplicating the text of the
interface with only a single change: e.g. a kernel interface exposed to
user space, with one function removed).
Here is a list of use cases for conditional compilation that I've come
across (note that it includes #ifdef in header files):
- disabling debug code,
- feature selection,
- choosing code path from constants,
- exposing/hiding interfaces depending on context,
The first three cases are just 'IF, but where the programmer wants to
guarantee that there is no runtime or code size overhead. These days,
with C compilers being good at constant propagation and inlining, as
well as dead code elimination, there is little need for #ifdef in these
cases (and GCC's __builtin_constant_p() helps). I suspect we continue to
use these because they very emphatically show that we are selecting code
paths based on compile-time information.
__builtin_constant_p() is often used as in:
#define BUILD_BUG_ON(x) (sizeof(char[1 - 2 * !!(x)]) - 1) /* eval to 0 */
#define BUILD_CNST(x) (BUILD_BUG_ON(!__builtin_constant_p(x)) || (x))
if (BUILD_CNST(has_feature)) {
/* ... */
}
Nice, eh? Having some kind of nicer support in BitC for checking that
compile-time optimisations will happen is very useful.
The last case may be more interesting, because I think you need support
at the language level.
int userspace_ok(void);
#ifdef KERNEL
int restricted(void);
#endif
int userspace_ok2(void);
One could argue that it's best to split the interface in two. I'm not
sure it makes things clearer to follow, though.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
