All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Magnus Lynch <maglyx@gmail.com>
Cc: Clemens Ladisch <clemens@ladisch.de>,
	"Venkatesh Pallipadi (Venki)" <venkatesh.pallipadi@intel.com>,
	"Vojtech Pavlik" <vojtech@suse.cz>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Paul Gortmaker" <paul.gortmaker@windriver.com>,
	"Suresh Siddha" <suresh.b.siddha@intel.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hpet: factor timer allocate from open
Date: Mon, 22 Mar 2010 15:21:03 -0700	[thread overview]
Message-ID: <20100322152103.86cfec45.akpm@linux-foundation.org> (raw)
In-Reply-To: <4ba2f862.4902be0a.0815.0d09@mx.google.com>

On Thu, 18 Mar 2010 21:06:58 -0700 (PDT)
Magnus Lynch <maglyx@gmail.com> wrote:

> Andrew Morton wrote:
> > Please always retain and maintain the changelog with each version of a patch.
> >
> > Please resend this patch with a complete changelog.
> 
> OK, here's my description from the original posting:
> <<
> The current implementation of the /dev/hpet driver couples opening the
> device with allocating one of the (scarce) timers (aka comparators).
> This is a limitation in that the main counter may be valuable to
> applications seeking a high-resolution timer who have no use for the
> interrupt generating functionality of the comparators.
> 
> This patch alters the open semantics so that when the device is
> opened, no timer is allocated. Operations that depend on a timer being
> in context implicitly attempt allocating a timer, to maintain backward
> compatibility. There is also an IOCTL (HPET_ALLOC_TIMER _IO) added so
> that the allocation may be done explicitly. (I prefer the explicit
> open then allocate pattern but don't know how practical it would be to
> require all existing code to be changed.)

A stylistic nit:

> @@ -384,6 +408,10 @@ static int hpet_fasync(int fd, struct file *file, int on)
>  {
>  	struct hpet_dev *devp;
>  
> +	int r = hpet_alloc_timer(file);
> +	if (r < 0)
> +		return r;
> +
>  	devp = file->private_data;
>  
>  	if (fasync_helper(fd, file, on, &devp->hd_async_queue) >= 0)
>
> ...
>
> @@ -438,6 +469,10 @@ hpet_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
>  {
>  	struct hpet_dev *devp;
>  
> +	int r = hpet_alloc_timer(file);
> +	if (r < 0)
> +		return r;
> +
>  	devp = file->private_data;
>  	return hpet_ioctl_common(devp, cmd, arg, 0);
>  }

The above constructs make it harder for people to modify the code
later.  If they want to add a new local, where to put it?  If they want
to add more code, where to put it?  Plus there are risks that people
will accidentally turn the code into c99-style definitions.

One could do

 {
 	struct hpet_dev *devp;
	int r = hpet_alloc_timer(file);

	if (r < 0)
		return r;


but that's not terribly good either: it adds risk that someone will
later add a leak.

Better is the plain old simple approach:


 {
 	struct hpet_dev *devp;
	int r;

	r = hpet_alloc_timer(file);
	if (r < 0)
		return r;



  reply	other threads:[~2010-03-22 22:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-01  5:30 [PATCH] hpet: factor timer allocate from open Magnus Lynch
2010-03-01  9:59 ` Clemens Ladisch
2010-03-01 20:24   ` Magnus Lynch
2010-03-01 20:59     ` john stultz
2010-03-03  9:07       ` Magnus Lynch
2010-03-03 16:26         ` john stultz
2010-03-10  2:47           ` Magnus Lynch
2010-03-04  2:59   ` Magnus Lynch
2010-03-04  8:43     ` Clemens Ladisch
2010-03-08  0:04       ` Magnus Lynch
2010-03-16 16:01         ` Clemens Ladisch
2010-03-18 19:11         ` Andrew Morton
2010-03-19  4:06           ` Magnus Lynch
2010-03-22 22:21             ` Andrew Morton [this message]
2010-03-23  2:02               ` Magnus Lynch

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=20100322152103.86cfec45.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=clemens@ladisch.de \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maglyx@gmail.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=venkatesh.pallipadi@intel.com \
    --cc=vojtech@suse.cz \
    /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.