[PATCH v2] ioctl: fix ioctl command number decoding in case of conflicts

[Gabriel Laskar]

On Mon, 30 Nov 2015 16:21:53 +0100
Patrik Jakobsson <patrik.r.jakobsson at gmail.com> wrote:

> On Mon, Nov 30, 2015 at 4:13 PM, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > On Mon, Nov 30, 2015 at 02:49:11PM +0100, Patrik Jakobsson wrote:  
> >> On Thu, Sep 24, 2015 at 2:45 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:  
> >> > On Wed, Sep 23, 2015 at 10:11:55AM +0200, Gabriel Laskar wrote:  
> >> >> When a command number was decoded through ioctl_decode_command_number(),
> >> >> there was no check for conflicts with other potential ioctls numbers.  
> >> >
> >> > Merged, thanks.  
> >>
> >> Hi, sorry for noticing this a bit late but this change makes it
> >> impossible to override the ioctl decoding for drm. The correct
> >> decoding can be done by identifying the driver and I need a way to
> >> stop the generic decoding at that point.  
> >
> > Do you mean that you want to be able to turn off ioctl_lookup completely?  
> 
> Yes that was my idea. ioctl_lookup() doesn't know about the drm driver
> backing the device so it cannot give us the correct ioctl.

I am working on a semi-automated generator for all ioctl decoding, and
I have the same kind of issues.

Identifying the correct device is a problem that is recurring in all
the ioctl decoding code. There is a some devices that have conflicting
numbers, having a way to know exactly which device it is, like gather
major/minor number, would allow to have the right set of ioctl. As it
is costly to do that, we can, for example enable this only when verbose
mode is activated, and fallback on just displaying the ioctl number on
the other cases.

I am preparing an rfc for all that.

-- 
Gabriel Laskar