From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755269AbdERI1G (ORCPT ); Thu, 18 May 2017 04:27:06 -0400 Received: from verein.lst.de ([213.95.11.211]:57431 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753486AbdERI1F (ORCPT ); Thu, 18 May 2017 04:27:05 -0400 Date: Thu, 18 May 2017 10:27:03 +0200 From: Christoph Hellwig To: Arnd Bergmann Cc: Christoph Hellwig , Thomas Gleixner , Tejun Heo , linuxppc-dev , Mark Gross , Linux Kernel Mailing List , linux-s390 Subject: Re: RFC: better timer interface Message-ID: <20170518082703.GD3812@lst.de> References: <20170516114812.10660-1-hch@lst.de> <20170516155132.GA1494@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.