Messages in this thread | | | From | Stephen Hemminger <> | Subject | Re: [ANNOUNCE] high-res-timers patches for 2.6.6 | Date | Tue, 22 Jun 2004 11:05:05 -0700 |
| |
> > Another thing that seems to be a sore point is the HRT core. I think > there's a good consensus that the current use of preprocessor > conditionals makes the code pretty hairy, but what alternatives are there?
The way to handle this is to abstract the needed interface into a set of inline's in one place (hrtime.h) then something like
#ifdef CONFIG_HIRES_TIMERS
static inline void update_hires(struct foo *foo) { foo->sub_tick = ... } #else
static inline void update_hires(struct foo *foo) { }
#endif
> If the HRT code is always compiled in, that would simplify things alot, > but then there would always be a small performance hit in the compares, > and a slightly bigger code size. Is this acceptable? Also, something > would need to be arranged to take care of the non-supported arch's. Any > ideas here?
There are two different questions. Should size of structures change based on config options, that is what tends to make binaries break. The other is whether the sub-tick stuff is implemented or not.
> Another way would be to pull out the HRT operations into separate > functions that could be conditionally included or replaced with no-op > versions based on a config option. I don't know if this would be > do-able, or if the result would be very clean though...
It is best if the conditional code is in only a few of places, like the inline's in an one include file; and the main code in timers plus any arch dependant stuff.
-- Stephen Hemminger mailto:shemminger@osdl.org Open Source Development Lab http://developer.osdl.org/shemminger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |