>From: Menon, Nishanth > >Apologies on the spam, but a few points below for preventing a future >ioctl change: > >Menon, Nishanth had written, on 01/07/2010 08:59 PM, the following: >> Ramirez Luna, Omar had written, on 01/07/2010 07:01 PM, the following: >>> - Use standard convention to define ioctls. >please warn in the commit message that this will break compatibility. >
Will do >>> - Removed runtime check for ioctl matching table number. >>> - Added __deprectaed marker to functions that are not used anymore. >generic idea: > if (cmd < ARRAY_SIZE(WCD_cmdTable)) { > /* make the fxn call via the cmd table */ > *pResult = (*WCD_cmdTable[cmd].fxn) (args, pr_ctxt); >if you convert this into: > if (!WCD_cmdTable[cmd].fxn) > return -EINVAL; > /* make the fxn call via the cmd table */ > *pResult = (*WCD_cmdTable[cmd].fxn) (args, pr_ctxt); >you'd make deprecation of a previously defined ioctl easy -> just NULL >and remove the function in the array and remove it and it's unused >helper functions.. :).. Problem comes if you are expecting some status value from that function > > >one generic question - I did not see an features/ioctls supported around >- having not dug enough, how does the userspace know if the bridge uses >the new ioctls/old ioctls? Patch will be sent to userspace repository on dev.omapzoom.org... the idea is to support this set of ioctls from now on... overall I don't think I got your question [snip] - omar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html