Alexander Aring wrote:
> I don't know if EINVAL the right errno here.
Yeah, I don't like EINVAL either. It seems that almost everything
that can possibly go wrong returns EINVAL, giving no clue what
actually happened.
But one issue is that some things expect specific error codes.
Looking for precedent, the closest thing I was able to find is
net/ieee802154/nl-phy.c:ieee802154_add_iface which returns
EINVAL if there's no phy->add_iface.
> Maybe we can use ENOTSUP
According to [1], ENOTSUP sounds as if it belonged to a specific
subsystem:
"Not supported. The implementation does not support this feature of
the Realtime Option Group."
If we decide to stray from EINVAL, maybe EOPNOTSUPP would be a
little closer:
"Operation not supported on socket. The type of socket (address
family or protocol) does not support the requested operation."
Another fairly common choice could be ENOSYS:
"Function not implemented. An attempt was made to use a function
that is not available in this implementation."
[1] IEEE Std 1003.1-2001, Section 2.3, Error Numbers
http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_03.html
- Werner
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
