Messages in this thread |  | | Date | Sun, 25 Apr 2010 10:49:51 -0700 (PDT) | | From | Linus Torvalds <> | | Subject | Re: [GIT PULL v2] Preparation for BKL'ed ioctl removal |
| |
On Sun, 25 Apr 2010, Frederic Weisbecker wrote: > > And to prepare for that, are you ok with this scheme of: > > - .ioctl = foo, > + .unlocked_ioctl = bkl_ioctl, > + .bkl_ioctl = foo, > > ...done at the same time as the big rename patch.
Seriously, why not just
- .ioctl = foo, + .bkl_ioctl = foo
because that line of
+ .unlocked_ioctl = bkl_ioctl,
is just total and utter _garbage_. There is zero reason for it.
In the long run (this is a year from now, when we rename "unlocked_ioctl" back to just "ioctl"), the vfs_ioctl code will just do
struct file_operations *fops = filp->f_op;
if (!fops) return -ENOTTY;
if (fops->ioctl) { int error = fops->ioctl(...) if (error == -ENOIOCTLCMD) error = -EINVAL; return error; } #ifdef CONFIG_BKL if (fops->bkl_ioctl) { int error; lock_kernel(); error = fops->bkl_ioctl(...) unlock_kernel(); return error; } #endif return -ENOTTY;
and we're all done.
At NO point is there any advantage to that "bkl_ioctl" crap. It doesn't help the legacy drivers (which won't even _compile_ unless CONFIG_BKL is set anyway), it doesn't help the core code, it doesn't help _anybody_.
Not today, not tomorrow, not with CONFIG_BKL, and not without.
Linus
|  |