>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
