changing EINVAL for SIOCSIFCAP to something else

[Gleb Smirnoff]

On Mon, Feb 27, 2006 at 01:20:30PM +0300, Yar Tikhiy wrote:
Y> > Y> > Y> I'm afraid that this is a case when EINVAL is used properly: an
Y> > Y> > Y> argument to ioctl doesn't make sense to a particular device.  It's
Y> > Y> > Y> true that EINVAL may be abused in other places though.  I wish each
Y> > Y> > Y> EINVAL being returned to the userland were accompanied by log().
Y> > Y> > 
Y> > Y> > I don't agree. EINVAL can logically fit to almost any error condition. We
Y> > Y> > should fine error codes fitting better. If "ioctl doesn't make sense to a
Y> > Y> > particular device", then we should say "Operation not supported by device",
Y> > Y> > which is ENODEV.
Y> > Y> 
Y> > Y> You see, it isn't ioctl itself that doesn't make sense to the device,
Y> > Y> it's a single argument, ifr_reqcap.  That was my point.  Of course,
Y> > 
Y> > Yes. The ioctl is correct, that's why we do not return ENOTTY. The
Y> > argument is correct, that's why we do not return EINVAL. The argument
Y> > is not applicable to this device, that's why I suggest to use ENODEV.
Y> 
Y> This interpretation sounds fair to me.  Did you look at other cases
Y> when ENODEV was returned?  How consistent were they with this one?

In network code only in if_setlladdr() if the device doesn't have link
level address at all.

In many places throughout the kernel, in most cases close to the description.

AFAIK, EINVAL is a correct choice, when argument is incorrect, for example
its length differs to the expected.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE