Re: [PATCH 01/18] lirc core device driver infrastructure

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Jonathan Corbet
Date: Tuesday, September 9, 2008 - 8:33 am

I think it's most cool that this code is finally making its way toward
the mainline.  What I have is mostly nits...

 ... 

kthread_stop() will wake up the process, so there is no need to do it
separately here.  In fact, it almost looks like the separate
wake_up_process() call could create an (unlikely) race where the thread
would miss the fact that it's supposed to stop and sleep again.  Fixing the
sleep_on() call there to use something like wait_event() would help in that
regard.



All of these might be better as iminor(inode)


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.

...

Why is there a set_use_inc() function separate from open()?


If "no owner" is a fatal condition, it seems better to check it when the
plugin is registered.  (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.)


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? 


Why two ioctl() handlers?  It seems better to just have one way for plugins
to handle this call.

...

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.

 ...

How can ir->attached go to zero?  You checked it earlier and have been
holding the mutex ever since.


Looks like you're using the "specific write function" instead :)


You should probably set .owner too.


Do you want to fail completely if class_create() fails?  What if somebody
already opened one of your devices?


All of these inlines probably shouldn't be.

jon
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 0/18] linux infrared remote control drivers, Jarod Wilson, (Mon Sep 8, 9:05 pm)
[PATCH 01/18] lirc core device driver infrastructure, Jarod Wilson, (Mon Sep 8, 9:05 pm)
[PATCH 05/18] lirc driver for i2c-based IR receivers, Jarod Wilson, (Mon Sep 8, 9:05 pm)
[PATCH 15/18] lirc driver for the SIR IrDA port, Jarod Wilson, (Mon Sep 8, 9:06 pm)
Re: [PATCH 0/18] linux infrared remote control drivers, Chris Wedgwood, (Mon Sep 8, 9:36 pm)
Re: [PATCH 0/18] linux infrared remote control drivers, Alexey Dobriyan, (Tue Sep 9, 12:06 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Sebastian Siewior, (Tue Sep 9, 12:40 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Janne Grunau, (Tue Sep 9, 1:32 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Sebastian Siewior, (Tue Sep 9, 5:33 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Christoph Hellwig, (Tue Sep 9, 5:46 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Hellwig, (Tue Sep 9, 6:01 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Stefan Richter, (Tue Sep 9, 6:27 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Jarod Wilson, (Tue Sep 9, 8:23 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Jonathan Corbet, (Tue Sep 9, 8:33 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Lennart Sorensen, (Tue Sep 9, 11:27 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Jarod Wilson, (Tue Sep 9, 11:34 am)
Re: [PATCH 02/18] lirc serial port receiver/transmitter de ..., Stefan Lippers-Hollmann, (Tue Sep 9, 12:51 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Hellwig, (Wed Sep 10, 5:29 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Dmitry Torokhov, (Wed Sep 10, 6:08 am)
Re: [PATCH 06/18] lirc driver for the ATI USB RF remote re ..., Christoph Hellwig, (Wed Sep 10, 6:14 am)
Re: [PATCH 06/18] lirc driver for the ATI USB RF remote re ..., Christoph Hellwig, (Wed Sep 10, 7:19 am)
Re: [PATCH 05/18] lirc driver for i2c-based IR receivers, Jonathan Corbet, (Wed Sep 10, 8:42 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Gerd Hoffmann, (Thu Sep 11, 1:47 am)
Re: [PATCH 09/18] lirc driver for the Streamzap PC Receiver, Jonathan Corbet, (Thu Sep 11, 8:22 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Thu Sep 11, 9:41 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Thu Sep 11, 11:03 am)
Re: [PATCH 07/18] lirc driver for the CommandIR USB Transc ..., Christoph Bartelmus, (Thu Sep 11, 11:24 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Thu Sep 11, 11:30 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Jarod Wilson, (Thu Sep 11, 12:09 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Janne Grunau, (Thu Sep 11, 12:18 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Maxim Levitsky, (Thu Sep 11, 2:28 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Dmitry Torokhov, (Thu Sep 11, 9:44 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Hellwig, (Fri Sep 12, 1:33 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Sat Sep 13, 12:20 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Sat Sep 13, 12:21 am)