From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3wT46f3YPfzDqk9 for ; Thu, 18 May 2017 18:27:06 +1000 (AEST) 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 In-Reply-To: List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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.