Re: [patch 25/43] Create ktimeout.h and move timer.h code into it

[Ingo Molnar <mingo@elte.hu>]

* Adrian Bunk <bunk@stusta.de> wrote:

> On Thu, Dec 01, 2005 at 01:03:48AM +0100, Thomas Gleixner wrote:
> > plain text document attachment (ktimeout-h.patch)
> > - introduce ktimeout.h and move the timeout implementation into it, as-is.
> > - keep timer.h for compatibility
> >...
> 
> If you do this, you should either immediately remove timer.h or add a
> #warning to this file.
> 
> Both cases imply changing all in-kernel users (which is anyway a good 
> idea if we really want to rename this header).

agreed, but we didnt want to be this drastic - we just wanted to 
demonstrate that a smooth transition (short of an overnight changeover) 
is possible as well.

also, we are very interested in suggestions to further improve the
ktimeout APIs. The perfect time is when there are no direct users of it
yet.

e.g. there's an interesting thought that Roman demonstrated in his 
ptimer queue: the elimination of the .data field from struct ktimer. An 
analogous thing could be done for timeouts as well: we do not actually 
need a .data field in a fair number of cases - the position of any 
data-context information can be recovered via container_of():

void timer_fn(struct ktimeout *kt)
{
	struct my_data *ptr = container_of(kt, struct my_data, timer);
	...
}

for compatibility we could provide a "struct ktimeout_standalone" that 
embedds a .data field and a struct timeout - which would be equivalent 
to the current "struct ktimeout".

the advantage would be data-structure size reduction of one word per 
embedded ktimeout structure. We'd also have one less word per standalone 
timer that needs no data field. For standalone timeouts which do need a 
data field there would be no impact.

one downside is that it's not as straightforward to code as the current 
.data field.

	Ingo
-
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/