All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janne Grunau <j@jannau.net>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Jarod Wilson <jwilson@redhat.com>,
	linux-kernel@vger.kernel.org, Jarod Wilson <jarod@redhat.com>,
	Christoph Bartelmus <lirc@bartelmus.de>,
	Mario Limonciello <superm1@ubuntu.com>
Subject: Re: [PATCH 01/18] lirc core device driver infrastructure
Date: Fri, 12 Sep 2008 02:12:33 +0200	[thread overview]
Message-ID: <200809120212.33716.j@jannau.net> (raw)
In-Reply-To: <20080909093308.0734a6ba@bike.lwn.net>

On Tuesday 09 September 2008 17:33:08 Jonathan Corbet wrote:
> I think it's most cool that this code is finally making its way
> toward the mainline.  What I have is mostly nits...

ignoring bits already handled in Christoph Hellwig's review

> > +		dprintk("lirc_dev [%d]: open result = -ENODEV\n",
> > +			MINOR(inode->i_rdev));
> > +		return -ENODEV;
> > +	}
> > +
> > +	ir = &irctls[MINOR(inode->i_rdev)];
> > +
> > +	dprintk(LOGHEAD "open called\n", ir->p.name, ir->p.minor);
> > +
> > +	/* if the plugin has an open function use it instead */
> > +	if (ir->p.fops && ir->p.fops->open)
> > +		return ir->p.fops->open(inode, file);
> > +
> > +	if (mutex_lock_interruptible(&plugin_lock))
> > +		return -ERESTARTSYS;
>
> So the plugin open() function is called outside of any lock.  Note
> that open() no longer has BKL protection as of 2.6.27.  This might
> all be OK, but I hope you're convinced of it.

plugins fops are called directly now

> > +	if (ir->p.owner != NULL && try_module_get(ir->p.owner)) {
> > +		++ir->open;
> > +		retval = ir->p.set_use_inc(ir->p.data);
>
> Why is there a set_use_inc() function separate from open()?

since not all plugins set p.fops? some of those functions in the drivers 
are even empty. I'll look at it.

> > +		if (retval != SUCCESS) {
> > +			module_put(ir->p.owner);
> > +			--ir->open;
> > +		}
> > +	} else {
> > +		if (ir->p.owner == NULL)
> > +			dprintk(LOGHEAD "no module owner!!!\n",
> > +				ir->p.name, ir->p.minor);
> > +
> > +		retval = -ENODEV;
> > +	}
>
> If "no owner" is a fatal condition, it seems better to check it when
> the plugin is registered.

maybe because it's not needed if the plugin has its own fops.open?

> (Also, BTW, your variant of dprintk() is 
> confusing to read - I was wondering where all the %'s were.  I still
> wonder, actually.  dev_printk() would be better.)

the LOGHEAD define is confusing, I'll look into make more clear

> > +static int irctl_close(struct inode *inode, struct file *file)
> > +{
> > +	struct irctl *ir = &irctls[MINOR(inode->i_rdev)];
> > +
> > +	dprintk(LOGHEAD "close called\n", ir->p.name, ir->p.minor);
> > +
> > +	/* if the plugin has a close function use it instead */
> > +	if (ir->p.fops && ir->p.fops->release)
> > +		return ir->p.fops->release(inode, file);
> > +
> > +	if (mutex_lock_interruptible(&plugin_lock))
> > +		return -ERESTARTSYS;
>
> Should this be interruptible?  You probably want the close call to
> get its job done.  Maybe mutex_lock_killable() - and still do the
> cleanup on a signal?

That's better than the current state.

> > +static int irctl_ioctl(struct inode *inode, struct file *file,
> > +		       unsigned int cmd, unsigned long arg)
> > +{
> > +	unsigned long mode;
> > +	int result;
> > +	struct irctl *ir = &irctls[MINOR(inode->i_rdev)];
> > +
> > +	dprintk(LOGHEAD "ioctl called (0x%x)\n",
> > +		ir->p.name, ir->p.minor, cmd);
> > +
> > +	/* if the plugin has a ioctl function use it instead */
> > +	if (ir->p.fops && ir->p.fops->ioctl)
> > +		return ir->p.fops->ioctl(inode, file, cmd, arg);
> > +
> > +	if (ir->p.minor == NOPLUG || !ir->attached) {
> > +		dprintk(LOGHEAD "ioctl result = -ENODEV\n",
> > +			ir->p.name, ir->p.minor);
> > +		return -ENODEV;
> > +	}
> > +
> > +	/* Give the plugin a chance to handle the ioctl */
> > +	if (ir->p.ioctl) {
> > +		result = ir->p.ioctl(inode, file, cmd, arg);
> > +		if (result != -ENOIOCTLCMD)
> > +			return result;
> > +	}
>
> Why two ioctl() handlers?  It seems better to just have one way for
> plugins to handle this call.

after a cursory look this is used if the plugin doesn't reimplement or 
want to overwrite the commands handled in irctl. I'll look if this can 
be handled better.

> > +	default:
> > +		result = -ENOIOCTLCMD;
>
> Hmm, I note with interest that unlocked_ioctl() remaps -ENOIOCTLCMD
> to -EINVAL, while regular, locked ioctl() (which this is) does not. 
> Not sure what to make of that.

changed this return value to -EINVAL

> > +static ssize_t irctl_read(struct file *file,
> > +			  char *buffer,
> > +			  size_t length,
> > +			  loff_t *ppos)
> > +{
>
>  ...
>
> > +			schedule();
> > +			set_current_state(TASK_INTERRUPTIBLE);
> > +			if (!ir->attached) {
> > +				ret = -ENODEV;
> > +				break;
> > +			}
>
> How can ir->attached go to zero?  You checked it earlier and have
> been holding the mutex ever since.

I don't think the lock has to be held while sleeping

> > +static ssize_t irctl_write(struct file *file, const char *buffer,
> > +			   size_t length, loff_t *ppos)
> > +{
> > +	struct irctl *ir =
> > &irctls[MINOR(file->f_dentry->d_inode->i_rdev)];
> > +	dprintk(LOGHEAD "write called\n", ir->p.name, ir->p.minor);
> > +
> > +	/* if the plugin has a specific read function use it instead
> > */
> > +	if (ir->p.fops && ir->p.fops->write)
> > +		return ir->p.fops->write(file, buffer, length, ppos);
>
> Looks like you're using the "specific write function" instead :)

plugins fops will be used directly now, no need for this comment and 
code anymore ;)

> > +static struct file_operations fops = {
> > +	.read		= irctl_read,
> > +	.write		= irctl_write,
> > +	.poll		= irctl_poll,
> > +	.ioctl		= irctl_ioctl,
> > +	.open		= irctl_open,
> > +	.release	= irctl_close
> > +};
>
> You should probably set .owner too.

done

> > +static int lirc_dev_init(void)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < MAX_IRCTL_DEVICES; ++i)
> > +		init_irctl(&irctls[i]);
> > +
> > +	if (register_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME, &fops))
> > {
> > +		printk(KERN_ERR "lirc_dev: register_chrdev
> > failed\n");
> > +		goto out;
> > +	}
> > +
> > +	lirc_class = class_create(THIS_MODULE, "lirc");
> > +	if (IS_ERR(lirc_class)) {
> > +		printk(KERN_ERR "lirc_dev: class_create failed\n");
> > +		goto out_unregister;
> > +	}
> > +
> > +	printk(KERN_INFO "lirc_dev: IR Remote Control driver
> > registered, "
> > +	       "major %d \n", IRCTL_DEV_MAJOR);
> > +
> > +	return SUCCESS;
> > +
> > +out_unregister:
> > +	/* unregister_chrdev returns void now */
> > +	unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME);
> > +out:
> > +	return -1;
> > +}
>
> Do you want to fail completely if class_create() fails?  What if
> somebody already opened one of your devices?

order reversed and using alloc_chrdev_region so there is no device which 
could be opened. Also returning correct error values now.

Thanks for the review.

Janne

  reply	other threads:[~2008-09-12  0:16 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-09  4:05 [PATCH 0/18] linux infrared remote control drivers Jarod Wilson
2008-09-09  4:05 ` [PATCH 01/18] lirc core device driver infrastructure Jarod Wilson
2008-09-09  4:05   ` [PATCH 02/18] lirc serial port receiver/transmitter device driver Jarod Wilson
2008-09-09  4:05     ` [PATCH 03/18] lirc driver for 1st-gen Media Center Ed. USB IR transceivers Jarod Wilson
2008-09-09  4:05       ` [PATCH 04/18] lirc driver for 2nd-gen and later " Jarod Wilson
2008-09-09  4:05         ` [PATCH 05/18] lirc driver for i2c-based IR receivers Jarod Wilson
2008-09-09  4:05           ` [PATCH 06/18] lirc driver for the ATI USB RF remote receiver Jarod Wilson
2008-09-09  4:05             ` [PATCH 07/18] lirc driver for the CommandIR USB Transceiver Jarod Wilson
2008-09-09  4:05               ` [PATCH 08/18] lirc driver for the Soundgraph IMON IR Receivers Jarod Wilson
2008-09-09  4:05                 ` [PATCH 09/18] lirc driver for the Streamzap PC Receiver Jarod Wilson
2008-09-09  4:05                   ` [PATCH 10/18] lirc driver for Igor Cesko's USB IR receiver Jarod Wilson
2008-09-09  4:05                     ` [PATCH 11/18] lirc driver for the Technotrend " Jarod Wilson
2008-09-09  4:05                       ` [PATCH 12/18] lirc driver for the Sasem OnAir and Dign HV5 receivers Jarod Wilson
2008-09-09  4:05                         ` [PATCH 13/18] lirc driver for ITE8709 CIR port receiver Jarod Wilson
2008-09-09  4:05                           ` [PATCH 14/18] lirc driver for the ITE IT87xx CIR Port receivers Jarod Wilson
2008-09-09  4:06                             ` [PATCH 15/18] lirc driver for the SIR IrDA port Jarod Wilson
2008-09-09  4:06                               ` [PATCH 16/18] lirc driver for the IR interface on BT829-based hardware Jarod Wilson
2008-09-09  4:06                                 ` [PATCH 17/18] lirc driver for homebrew parallel port receivers Jarod Wilson
2008-09-09  4:06                                   ` [PATCH 18/18] lirc driver for the zilog/haupauge IR transceiver Jarod Wilson
2008-09-09  4:06                                     ` Jarod Wilson
2008-09-11 15:22                   ` [PATCH 09/18] lirc driver for the Streamzap PC Receiver Jonathan Corbet
2008-09-10 21:02                 ` [PATCH 08/18] lirc driver for the Soundgraph IMON IR Receivers Jonathan Corbet
2008-09-10 21:23                   ` Janne Grunau
2008-09-11  3:22                     ` Jarod Wilson
2008-09-22 21:47                   ` Jarod Wilson
2008-09-24 20:21                     ` Jarod Wilson
2008-09-10 17:09               ` [PATCH 07/18] lirc driver for the CommandIR USB Transceiver Jonathan Corbet
2008-09-11 18:24                 ` Christoph Bartelmus
     [not found]                   ` <1221159005.13683.34.camel@minimatt>
2008-09-11 19:03                     ` Jarod Wilson
2008-09-11 19:14                     ` Janne Grunau
2008-09-25 15:21                 ` Jarod Wilson
2008-09-10  9:58             ` [PATCH 06/18] lirc driver for the ATI USB RF remote receiver Ville Syrjälä
2008-09-10 13:05               ` Jarod Wilson
2008-09-10 13:14                 ` Christoph Hellwig
2008-09-10 13:37                   ` Jon Smirl
2008-09-10 14:30                     ` Dmitry Torokhov
2008-09-10 13:44                   ` Janne Grunau
2008-09-10 14:13                     ` Jarod Wilson
2008-09-10 14:19                     ` Christoph Hellwig
2008-09-10 14:08                 ` Ville Syrjälä
2008-09-10 14:37                   ` Dmitry Torokhov
2008-09-09  4:13           ` [PATCH 05/18] lirc driver for i2c-based IR receivers Jarod Wilson
2008-09-10 15:42           ` Jonathan Corbet
2008-09-09 23:30         ` [PATCH 04/18] lirc driver for 2nd-gen and later Media Center Ed. USB IR transceivers Jonathan Corbet
2008-09-10  0:36           ` Janne Grunau
2008-09-11  9:21           ` Adrian Bunk
2008-09-09 19:21       ` [PATCH 03/18] lirc driver for 1st-gen " Jonathan Corbet
2008-09-09 23:59         ` Janne Grunau
2008-09-10  1:39           ` Jarod Wilson
2008-09-10  0:04         ` Janne Grunau
2008-09-09 16:14     ` [PATCH 02/18] lirc serial port receiver/transmitter device driver Jonathan Corbet
2008-09-09 19:51       ` Stefan Lippers-Hollmann
2008-09-09 19:56         ` Jarod Wilson
2008-09-10 17:40       ` Jarod Wilson
2008-09-09  7:40   ` [PATCH 01/18] lirc core device driver infrastructure Sebastian Siewior
2008-09-09  9:53     ` Janne Grunau
2008-09-09 12:33       ` Sebastian Siewior
2008-09-09 13:10         ` Janne Grunau
2008-09-11 16:41       ` Christoph Bartelmus
2008-09-09 11:13     ` Alan Cox
2008-09-09 13:27     ` Stefan Richter
2008-09-09 17:03     ` Jarod Wilson
2008-09-11 18:30       ` Christoph Bartelmus
2008-09-11 19:09         ` Jarod Wilson
2008-09-13  7:21           ` Christoph Bartelmus
2008-09-09  9:46   ` Andi Kleen
2008-09-09 11:35     ` Janne Grunau
2008-09-09 13:03       ` Andi Kleen
2008-09-09 13:20         ` Janne Grunau
2008-09-12 16:46           ` Greg KH
2008-09-09 13:01   ` Christoph Hellwig
2008-09-10 12:24     ` Janne Grunau
2008-09-10 12:29       ` Christoph Hellwig
2008-09-10 12:45         ` Janne Grunau
2008-09-11 18:03       ` Christoph Bartelmus
2008-09-11 19:18         ` Janne Grunau
2008-09-12  0:16     ` Janne Grunau
2008-09-12  8:33       ` Christoph Hellwig
2008-09-12 14:51         ` Jarod Wilson
2008-09-09 15:33   ` Jonathan Corbet
2008-09-12  0:12     ` Janne Grunau [this message]
2008-09-10 13:08   ` Dmitry Torokhov
2008-09-11  8:47     ` Gerd Hoffmann
2008-09-11 21:28       ` Maxim Levitsky
2008-09-13  7:20         ` Christoph Bartelmus
2008-09-12  4:44       ` Dmitry Torokhov
2008-09-09  4:36 ` [PATCH 0/18] linux infrared remote control drivers Chris Wedgwood
2008-09-09  7:06 ` Alexey Dobriyan
2008-09-09  8:32   ` Janne Grunau
2008-09-09 12:46 ` Christoph Hellwig
2008-09-09 15:23   ` Jarod Wilson
2008-09-09 18:27     ` Lennart Sorensen
2008-09-09 18:34       ` Jarod Wilson
2008-09-09 15:34   ` Jon Smirl

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=200809120212.33716.j@jannau.net \
    --to=j@jannau.net \
    --cc=corbet@lwn.net \
    --cc=jarod@redhat.com \
    --cc=jwilson@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lirc@bartelmus.de \
    --cc=superm1@ubuntu.com \
    /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.