Andrew Morton wrote:
> "Stone, Joshua I" <[email protected]> wrote:
>> I have noticed that the hrtimer APIs in 2.6.16 RCs are not exported,
>> and therefore modules are unable to use hrtimers. I have not seen
>> any discussion on this point, so I presume that this is either an
>> oversight, or there has not been any case presented for exporting
>> hrtimers.
>>
>> I would like to add hrtimer support to SystemTap, which by design
>> requires the use of dynamically loaded kernel modules. Can the
>> appropriate exports for hrtimers please be added?
>
> Please send a patch, so we can see what's needed.
>
> EXPORT_SYMBOL_GPL would be preferred.
This patch adds the exports needed for modules to use the
hrtimer APIs.
Signed-off-by: Josh Stone <[email protected]>
--- linux-2.6.16-rc6/kernel/hrtimer.c 2006-03-14 10:44:13.000000000
-0800
+++ linux-2.6.16-rc6-hrtexp/kernel/hrtimer.c 2006-03-14
11:13:48.000000000 -0800
@@ -238,6 +238,7 @@ ktime_t ktime_add_ns(const ktime_t kt, u
return ktime_add(kt, tmp);
}
+EXPORT_SYMBOL_GPL(ktime_add_ns);
#else /* CONFIG_KTIME_SCALAR */
@@ -319,6 +320,7 @@ hrtimer_forward(struct hrtimer *timer, k
return orun;
}
+EXPORT_SYMBOL_GPL(hrtimer_forward);
/*
* enqueue_hrtimer - internal function to (re)start a timer
@@ -439,6 +441,7 @@ hrtimer_start(struct hrtimer *timer, kti
return ret;
}
+EXPORT_SYMBOL_GPL(hrtimer_start);
/**
* hrtimer_try_to_cancel - try to deactivate a timer
@@ -467,6 +470,7 @@ int hrtimer_try_to_cancel(struct hrtimer
return ret;
}
+EXPORT_SYMBOL_GPL(hrtimer_try_to_cancel);
/**
* hrtimer_cancel - cancel a timer and wait for the handler to finish.
@@ -486,6 +490,7 @@ int hrtimer_cancel(struct hrtimer *timer
return ret;
}
}
+EXPORT_SYMBOL_GPL(hrtimer_cancel);
/**
* hrtimer_get_remaining - get remaining time for the timer
@@ -504,6 +509,7 @@ ktime_t hrtimer_get_remaining(const stru
return rem;
}
+EXPORT_SYMBOL_GPL(hrtimer_get_remaining);
#ifdef CONFIG_NO_IDLE_HZ
/**
@@ -538,6 +544,7 @@ ktime_t hrtimer_get_next_event(void)
mindelta.tv64 = 0;
return mindelta;
}
+EXPORT_SYMBOL_GPL(hrtimer_get_next_event);
#endif
/**
@@ -561,6 +568,7 @@ void hrtimer_init(struct hrtimer *timer,
timer->base = &bases[clock_id];
}
+EXPORT_SYMBOL_GPL(hrtimer_init);
/**
* hrtimer_get_res - get the timer resolution for a clock
@@ -580,6 +588,7 @@ int hrtimer_get_res(const clockid_t whic
return 0;
}
+EXPORT_SYMBOL_GPL(hrtimer_get_res);
/*
* Expire the per base hrtimer-queue:
@@ -761,6 +770,7 @@ long hrtimer_nanosleep(struct timespec *
return -ERESTART_RESTARTBLOCK;
}
+EXPORT_SYMBOL_GPL(hrtimer_nanosleep);
asmlinkage long
sys_nanosleep(struct timespec __user *rqtp, struct timespec __user
*rmtp)
"Stone, Joshua I" <[email protected]> wrote:
>
> Andrew Morton wrote:
> > "Stone, Joshua I" <[email protected]> wrote:
> >> I have noticed that the hrtimer APIs in 2.6.16 RCs are not exported,
> >> and therefore modules are unable to use hrtimers. I have not seen
> >> any discussion on this point, so I presume that this is either an
> >> oversight, or there has not been any case presented for exporting
> >> hrtimers.
> >>
> >> I would like to add hrtimer support to SystemTap, which by design
> >> requires the use of dynamically loaded kernel modules. Can the
> >> appropriate exports for hrtimers please be added?
> >
> > Please send a patch, so we can see what's needed.
> >
> > EXPORT_SYMBOL_GPL would be preferred.
>
> This patch adds the exports needed for modules to use the
> hrtimer APIs.
>
> --- linux-2.6.16-rc6/kernel/hrtimer.c 2006-03-14 10:44:13.000000000
> -0800
> +++ linux-2.6.16-rc6-hrtexp/kernel/hrtimer.c 2006-03-14
> 11:13:48.000000000 -0800
Wordwrapped...
> +EXPORT_SYMBOL_GPL(ktime_add_ns);
> +EXPORT_SYMBOL_GPL(hrtimer_forward);
> +EXPORT_SYMBOL_GPL(hrtimer_start);
> +EXPORT_SYMBOL_GPL(hrtimer_try_to_cancel);
> +EXPORT_SYMBOL_GPL(hrtimer_cancel);
> +EXPORT_SYMBOL_GPL(hrtimer_get_remaining);
> +EXPORT_SYMBOL_GPL(hrtimer_get_next_event);
> +EXPORT_SYMBOL_GPL(hrtimer_init);
> +EXPORT_SYMBOL_GPL(hrtimer_get_res);
> +EXPORT_SYMBOL_GPL(hrtimer_nanosleep);
gee, that's a lot of exports. I don't know whether all of these would be
considered stable over the long-term?
Can you tell us a bit about why systemtap modules need the hrtimer
capability? How it's being used and for what, etc?
Thanks.
On Tue, Mar 14, 2006 at 01:36:33PM -0800, Andrew Morton wrote:
> gee, that's a lot of exports. I don't know whether all of these would be
> considered stable over the long-term?
No, their not. And until systemtap people actually cooperate with us
and put their library functionality do to thing like variable lookups
based on dward/unwinder info into that tree we shouldn't help them at all.
Andrew Morton wrote:
> Wordwrapped...
Yes, Outlook/Exchange betrayed me... sorry.
> gee, that's a lot of exports. I don't know whether all of these
> would be considered stable over the long-term?
For that first patch, I simply looked for the functions that looked
appropriate for general users of hrtimers. If you would like to be more
conservative, these five are all I need for SystemTap:
EXPORT_SYMBOL_GPL(ktime_add_ns);
EXPORT_SYMBOL_GPL(hrtimer_forward);
EXPORT_SYMBOL_GPL(hrtimer_start);
EXPORT_SYMBOL_GPL(hrtimer_cancel);
EXPORT_SYMBOL_GPL(hrtimer_init);
> Can you tell us a bit about why systemtap modules need the hrtimer
> capability? How it's being used and for what, etc?
Sure - SystemTap uses timers to provide an asynchronous probe during
module execution. This might be utilized for polling kernel states, for
flushing trace data, and perhaps other similar uses. Currently we're
using the main timer APIs - add_timer, mod_timer, etc.
My motivation for moving to hrtimer is because of what I read in its
documentation - basically that the timer wheel is best for timeout cases
which are rarely recascaded. The way SystemTap uses timers is more for
defining intervals, and they are always cascaded until the module is
complete. The hrtimers seem more suited to this methodology.
Correct me if I'm wrong...
Josh
On Tue, 2006-03-14 at 14:11 -0800, Stone, Joshua I wrote:
> Sure - SystemTap uses timers to provide an asynchronous probe during
> module execution. This might be utilized for polling kernel states, for
> flushing trace data, and perhaps other similar uses. Currently we're
> using the main timer APIs - add_timer, mod_timer, etc.
>
> My motivation for moving to hrtimer is because of what I read in its
> documentation - basically that the timer wheel is best for timeout cases
> which are rarely recascaded. The way SystemTap uses timers is more for
> defining intervals, and they are always cascaded until the module is
> complete. The hrtimers seem more suited to this methodology.
What means "more for defining intervals" ? Which intervals (period in
ms)? What are the timers used for ?
tglx