Re: [ANNOUNCE] high-res-timers patches for 2.6.6

[Stephen Hemminger]

> 
> 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@xxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/