From: Christoph Hellwig <hch@lst.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@lst.de>,
Thomas Gleixner <tglx@linutronix.de>, Tejun Heo <tj@kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Mark Gross <mark.gross@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: RFC: better timer interface
Date: Thu, 18 May 2017 10:27:03 +0200 [thread overview]
Message-ID: <20170518082703.GD3812@lst.de> (raw)
In-Reply-To: <CAK8P3a3_Rjz9gTmayN1w8HrFHWY+wakeFgQSYRTAADJzF6zKJA@mail.gmail.com>
On Tue, May 16, 2017 at 10:26:39PM +0200, Arnd Bergmann wrote:
> If we keep the unusual *_timer() naming (rather than timer_*() as hrtimer
> has), we could use one of
>
> a) start_timer(struct timer_list *timer, unsigned long ms);
> b) restart_timer(struct timer_list *timer, unsigned long ms);
> c) mod_timer_ms(struct timer_list *timer, unsigned long ms);
> mod_timer_sec(struct timer_list *timer, unsigned long sec);
>
> The first is slightly shorter but conflicts with three files that use
> the same name for a local function name. The third one fits
> well with the existing interfaces and provides both millisecond
> and second versions, I'd probably go with that.
Yeah, I'd take c) as well. I'll give it a spin.
> We could consider even passing a default interval as another
> argument to prepare_timer(), and using that in add_timer(),
> but that would in those cases that have a constant interval
> (maybe about half of the users from) and would be a bit surprising
> to readers that are only familiar with the existing interfaces.
That seems rather ugly to me.
> One final option would be a larger-scale replacement of
> the API by mirroring the hrtimer style where possible while
> staying compatible with the existing calls, e.g. timer_prepare(),
> timer_add_expires(), timer_start(), ...
I'd chose timer_* for an entirely new API, but at this point this
seems a bit too much churn to me.
next prev parent reply other threads:[~2017-05-18 8:27 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-16 11:48 RFC: better timer interface Christoph Hellwig
2017-05-16 11:48 ` [PATCH 1/9] timers: remove the fn and data arguments to call_timer_fn Christoph Hellwig
2017-05-16 11:48 ` [PATCH 2/9] timers: provide a "modern" variant of timers Christoph Hellwig
2017-05-16 19:29 ` Randy Dunlap
2017-05-16 20:03 ` Arnd Bergmann
2017-05-18 8:24 ` Christoph Hellwig
2017-05-18 8:41 ` Christoph Hellwig
2017-05-18 8:57 ` Arnd Bergmann
2017-05-21 7:00 ` Christoph Hellwig
2017-05-21 12:29 ` Arnd Bergmann
2017-05-21 17:57 ` Thomas Gleixner
2017-05-21 18:23 ` Al Viro
2017-05-19 10:48 ` David Laight
2017-05-21 6:57 ` 'Christoph Hellwig'
2017-05-16 11:48 ` [PATCH 3/9] kthread: remove unused macros Christoph Hellwig
2017-05-17 12:09 ` Petr Mladek
2017-05-17 12:09 ` Petr Mladek
2017-05-18 8:22 ` Christoph Hellwig
2017-05-16 11:48 ` [PATCH 4/9] workqueue: switch to modern timers Christoph Hellwig
2017-05-16 11:48 ` [PATCH 5/9] powerpc/numa: switch topology_timer to modern timer Christoph Hellwig
2017-05-16 11:48 ` [PATCH 6/9] s390: switch topology_timer to a " Christoph Hellwig
2017-05-16 11:48 ` [PATCH 7/9] s390: switch lgr timer " Christoph Hellwig
2017-05-16 11:48 ` [PATCH 8/9] tlclk: switch switchover_timer " Christoph Hellwig
2017-05-16 11:48 ` [PATCH 9/9] timers: remove old timer initialization macros Christoph Hellwig
2017-05-16 19:43 ` Arnd Bergmann
2017-05-18 8:25 ` Christoph Hellwig
2017-05-16 15:45 ` RFC: better timer interface Arnd Bergmann
2017-05-16 15:51 ` Christoph Hellwig
2017-05-16 20:26 ` Arnd Bergmann
2017-05-18 8:27 ` Christoph Hellwig [this message]
2017-05-21 17:13 ` Thomas Gleixner
2017-05-21 18:14 ` Thomas Gleixner
2017-05-22 11:26 ` Arnd Bergmann
2017-05-22 19:24 ` Thomas Gleixner
2017-05-23 11:36 ` David Laight
2017-05-23 11:36 ` David Laight
2017-05-23 11:58 ` Thomas Gleixner
2017-05-23 12:51 ` David Laight
2017-05-23 12:51 ` David Laight
2017-05-23 13:02 ` Thomas Gleixner
2017-05-22 13:32 ` Arnd Bergmann
2017-05-22 19:14 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170518082703.GD3812@lst.de \
--to=hch@lst.de \
--cc=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.gross@intel.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.