Cc: Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>, Peter Zijlstra <a.p.zijlstra@...>, Thomas Gleixner <tglx@...>, Alan Cox <alan@...>, Alexander Viro <viro@...>, <linux-kernel@...>
There's also every char device open() method - a rather long list in its
own right. I'd be surprised if one in ten of them really needs it, but
one has to look...
I've been looking at the chrdev code anyway, and pondering on how this
might be addressed. Here's some thoughts on alternatives, I'd be
curious what people think:
1: We could add an unlocked_open() to the file_operations structure;
drivers could be converted over as they are verified not to need the
BKL on open. Disadvantages are that it grows this structure for a
relatively rare case - most open() calls already don't need the BKL.
But it's a relatively easy path without flag days.
2: Create a char_dev_ops structure for char devs and use it instead of
file_operations. I vaguely remember seeing Al mutter about that a
while back. Quite a while back. This mirrors what was done with
block devices, and makes some sense - there's a lot of stuff in
struct file_operations which is not really applicable to char devs.
Then struct char_dev_ops could have open() and locked_open(), with
the latter destined for removal sometime around 2015 or so.
Advantages are that it's cleaner and separates out some things which
perhaps shouldn't be mixed anyway. Disadvantage is...well...a fair
amount of code churn. It would also require chrdev-specific wrappers
to map straight file_operations calls in the VFS to the new
callbacks.
3: Provide a new form of cdev_add() which lets the driver indicate
that the BKL is not needed on open (or anything else?). At a
minimum, it could just be a new parameter on cdev_add which has a
value of zero or FIXME_I_STILL_NEED_BKL. Still some churn but easier
to script and smaller because a lot of drivers are still using
register_chrdev() - something else worth fixing.
A more involved form might provide a new chardev_add() which takes
the new char_dev_ops structure too. Mapping between new and old
operations vectors would be done internally to avoid breaking older
drivers before they can be fixed.
4: Just find every char dev open() function and shove in lock_kernel()
calls, then remove the call from chrdev_open(). The disadvantage
here is that, beyond lots of work and churn, there's no way to know
which ones you missed.
I kind of like the combination of 2 and 3, done in such a way that
there's no "every driver must change" flag day. This could be an
interesting project, even... Thoughts?
jon
--
