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
--