Re: [patch 00/21] hrtimer - High-resolution timer subsystem

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> wrote:

> Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> >
> > We decided to rename 'ktimer' because Andrew pretty much vetoed the
> >  'ktimeout' queue

let me defuse things a bit here: the above sentence might sound a bit 
bitter, but we really, truly are not. You were more like the sane voice 
slapping us back into reality: for the next 2 years we do not want to be 
buried in tons of timer_list->ktimeout patches, causing disruption all 
across the kernel (and external trees). You definitely did not 'veto' it 
in any way, and in fact you are carrying it in -mm currently.

I did the ktimeout queue in an hour or so, and i dont have strong
feelings about it. I very much agree with you that a mass rename could
easily cause more problems than the added clarity adds - still i had to
try the ktimeout queue, because i'm hopelessly purist at heart :)

Maybe in a few years all substantial kernel code will be managed by a 
network of GIT repositories, and GIT will be extended with automatic 
'mass namespace change' capabilities, making an overnight switchover 
much more practical.

> Well I whined about the rename of timer_list to ktimeout and asked why 
> it happened.  I don't think anyone replied.

we thought we had this issue covered way too many times :) but find 
below my original justification for the ktimeout patch-queue. This is 
just for historical interest now i think.

[ insert the text below here. Time passes as everyone reads it :-) ]

once we take 'mass change of timer_list to ktimeout' out of the possible 
things to do, we've only got these secondary possibilities:

	'struct timer_list, struct ktimer'
	'struct timer_list, struct ptimer'
	'struct timer_list, struct hrtimer'

and having eliminated the first option due to being impractical to pull 
off, we had the choice between 'ptimer' and 'hrtimer', and went for the 
last one, for the following reason [snipped from a mail to Roman]:

| we decided against "ptimer" because it could be confused with "process 
| timers" and "posix timers". hrtimers is a clear term that indicates 
| what those timers do, so we picked up Andrew's suggestion as a way out 
| the endless naming discussion.

but really ... facing an imperfect naming situation (i do not think 
timer_list is the correct name - just as much as struct inode_list would 
not be correct - but it is the historic name and i think you are right 
that we've got to live with it) i'm alot less passionate about which one 
to pick. If we had the chance to have perfect naming, i'd definitely 
spend the effort to get it right, but now lets just go with the most 
descriptive one: 'struct hrtimer'.

	Ingo

-----
regarding naming. This is something best left to native speakers, but 
i'm not giving up the issue just yet :-)

i always sensed and agreed that 'struct ktimer' and 'struct timer_list' 
together is confusing. Same for kernel/ktimers.c and kernel/timers.c. So 
no argument about that, this situation cannot continue.

but the reason i am still holding on to 'struct ktimer' is that i think 
the end result should be:

 - 'struct ktimer' (for precise timers where the event of expiry is the 
                    main function)

 - 'struct ktimeout' (for the wheel-based timeouts, where expiry is an 
                      exception)

Similarly, kernel/ktimer.c for ktimers, and kernel/ktimeout.c for 
timeouts.

see the attached finegrained patchqueue that does all the changes to 
rename 'timers' to 'timeouts' [and to clean up the resulting subsystem], 
to see what i'm trying to achieve.

For now i'm ignoring the feasibility of a 'mass API change' issues - 
those are better up to lkml. The queue does build and compile fine on a 
rather big .config so the only question is - do we want it. Note that 
the patch does not have to touch even a single non-subsystem user of the 
timer.c APIs, so the renaming is robust.

IMO it looks a lot less confusing and dualistic that way. The rename is 
technically feasible and robust mainly because we can do this:

#define timer_list timeout

for the transition period (see the patch-queue). Fortunately timer_list 
is not a generic name. (it's also an incorrect name because it implies 
implementation) Here's the full list of mappings that occur:

#define timer_list			ktimeout

#define TIMER_INITIALIZER		KTIMEOUT_INITIALIZER 
#define DEFINE_TIMER			DEFINE_KTIMEOUT
#define init_timer			ktimeout_init
#define setup_timer			ktimeout_setup
#define timer_pending			ktimeout_pending
#define add_timer_on			ktimeout_add_on
#define del_timer			ktimeout_del
#define __mod_timer			__ktimeout_mod
#define mod_timer			ktimeout_mod
#define next_timer_interrupt		ktimeout_next_interrupt
#define add_timer			ktimeout_add
#define try_to_del_timer_sync		ktimeout_try_to_del_sync
#define del_timer_sync			ktimeout_del_sync
#define del_singleshot_timer_sync	ktimeout_del_singleshot_sync
#define init_timers			init_ktimeouts
#define run_local_timers		run_local_ktimeouts

but maybe 'struct ptimer' and 'struct ktimeout' is the better choice? I 
dont think so, but it's a possibility.

so i believe that:

	- 'struct ktimer', 'struct ktimeout'

is in theory superior naming, compared to:

	- 'struct ptimer', 'struct timer_list'

again, ignoring all the 'do we want to have a massive namespace change' 
issues.

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