public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Patrick Pannuto <ppannuto@codeaurora.org>
Cc: linux-kernel@vger.kernel.org, apw@canonical.com, corbet@lwn.net,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Akinobu Mita <akinobu.mita@gmail.com>
Subject: Re: [PATCH 1/4] timer: Added usleep[_range] timer
Date: Wed, 28 Jul 2010 14:23:34 -0700	[thread overview]
Message-ID: <20100728142334.a0453c20.akpm@linux-foundation.org> (raw)
In-Reply-To: <4C509BA3.7090403@codeaurora.org>

On Wed, 28 Jul 2010 14:05:39 -0700
Patrick Pannuto <ppannuto@codeaurora.org> wrote:

> On 07/28/2010 01:58 PM, Andrew Morton wrote:
> > On Wed, 28 Jul 2010 13:47:46 -0700
> > Patrick Pannuto <ppannuto@codeaurora.org> wrote:
> > 
> >>> This is different from the patch I merged and I'm not seeing any
> >>> explanation for the change.
> >>>
> >>> The implementation of usleep() looks odd.  The longer we sleep, the
> >>> greater the possible inaccuracy.  A code comment which explains the
> >>> thinking and which warns people about the implications is needed.
> > 
> > I wanna code comment!
> > 
> 
> I understand -- will do (if this even survives, which is unlikely)
> 
> > My main concern is that someone will type usleep(50) and won't realise
> > that it goes and sleeps for 100 usecs and their code gets slow as a
> > result.  This sort of thing takes *years* to discover and fix.  If we'd
> > forced them to type usleep_range() instead, it would never have happened.
> 
> In that case, it would push me in the direction of only providing
> usleep_range, and thus forcing people to think about it that way;
> leave slack decisions to people who know what tolerances are acceptable.

Well, I _think_ that would be a good approach.  I'm 45%/55% on that one
and would be interested in other opinions ;)


  reply	other threads:[~2010-07-28 21:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-28 19:33 [PATCH v2 0/4] timer: Added usleep[_range] timer Patrick Pannuto
2010-07-28 19:33 ` [PATCH 1/4] " Patrick Pannuto
2010-07-28 20:23   ` Andrew Morton
2010-07-28 20:47     ` Patrick Pannuto
2010-07-28 20:58       ` Andrew Morton
2010-07-28 21:04         ` Arjan van de Ven
2010-07-28 21:11           ` Patrick Pannuto
2010-07-28 21:22           ` Andrew Morton
2010-07-28 21:25             ` Arjan van de Ven
2010-07-28 21:05         ` Patrick Pannuto
2010-07-28 21:23           ` Andrew Morton [this message]
2010-07-28 21:26             ` Arjan van de Ven
2010-07-28 19:33 ` [PATCH 2/4] Documentation: Add timers/timers-howto.txt Patrick Pannuto
2010-07-28 19:33 ` [PATCH 3/4] Checkpatch: prefer usleep over udelay Patrick Pannuto
2010-07-28 20:24   ` Andrew Morton
2010-07-28 19:33 ` [PATCH 4/4] Checkpatch: warn about unexpectedly long msleep's Patrick Pannuto
2010-07-28 20:24   ` Andrew Morton
2010-07-28 20:48     ` Patrick Pannuto
2010-08-03 19:12 ` [PATCH v2 0/4] timer: Added usleep[_range] timer Pavel Machek

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=20100728142334.a0453c20.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=akinobu.mita@gmail.com \
    --cc=apw@canonical.com \
    --cc=arjan@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=ppannuto@codeaurora.org \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox