Messages in this thread | | | Date | Wed, 15 Dec 2004 20:21:09 +0200 | From | "Michael S. Tsirkin" <> | Subject | Re: unregister_ioctl32_conversion and modules. ioctl32 revisited. |
| |
Hello! Quoting r. Arnd Bergmann (arnd@arndb.de) "Re: unregister_ioctl32_conversion and modules. ioctl32 revisited.": > On Middeweken 15 Dezember 2004 17:57, Andi Kleen wrote: > > > Do you mean it should call back > > > from its private ioctl_compat() function to the global > ioctl32_hash_table[] > > > lookup? > > > > Yes. > > > > Some ioctl paths already work this way, e.g. in the block layer. > > Hmm. I just had another idea. Maybe it's easier to return -ENOIOCTLCMD > from ->ioctl_compat() in order to get back to the hash lookup. How > about the change below? > > Arnd <>< > > --- mst/fs/compat.c > +++ arnd/fs/compat.c > @@ somewhere in compat_sys_ioctl() @@ > else if (filp->f_op && filp->f_op->ioctl_compat) { > error = > filp->f_op->ioctl_compat(filp->f_dentry->d_inode, > filp, cmd, arg); > - goto out; > + if (error != -ENOIOCTLCMD) > + goto out; > } >
But what if you really wanted to return -ENOIOCTLCMD? And, the idea was to get rid of the hash eventually?
MST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |