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

From: Ingo Molnar
Date: Wed Dec 07 2005 - 05:11:49 EST



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