ENOIOCTLCMD?

ENOIOCTLCMD?

[Jonathan Lundell]

Can somebody explain the use of ENOIOCTLCMD? There are order of 170 
uses in the kernel, but I don't see any guidelines for that use (nor 
what prevents it from being seen by user programs).

Thanks.

errno.h:

>/* Should never be seen by user programs */
>#define ERESTARTSYS	512
>#define ERESTARTNOINTR	513
>#define ERESTARTNOHAND	514	/* restart if no handler.. */
>#define ENOIOCTLCMD	515	/* No ioctl command */

-- 
/Jonathan Lundell.

Re: ENOIOCTLCMD?

[Andi Kleen]

On Fri, May 11, 2001 at 10:01:50PM -0700, Jonathan Lundell wrote:
> Can somebody explain the use of ENOIOCTLCMD? There are order of 170 
> uses in the kernel, but I don't see any guidelines for that use (nor 
> what prevents it from being seen by user programs).

The idea with ENOIOCTLCMD is that when you have multiple subsystem 
callbacks (e.g. to low level drivers) the higher levels can pass the ioctls
down and they return ENOIOCTLCMD when they don't know the ioctl number,
so other subsystems can be tried.
This is nicer than using EINVAL, because EINVAL is a terminal condition.
The higher layer should always convert it into EINVAL if there is not
another callback to call, but if it leaks it is probably a bug.


-Andi

Re: ENOIOCTLCMD?

[Alan Cox]

> Can somebody explain the use of ENOIOCTLCMD? There are order of 170 
> uses in the kernel, but I don't see any guidelines for that use (nor 
> what prevents it from being seen by user programs).

It should never be seen by apps. If it can be then it is wrong code.
Basically you use it in things like



	int err = dev->ioctlfunc(dev, op, arg);
	if( err != -ENOIOCTLCMD)
		return err;

	/* Driver specific code does not support this ioctl */

	switch(op)
	{

			...
		default:
			return -ENOTTY;
	}

Its a way of passing back 'you handle it' 

Re: ENOIOCTLCMD?

[Mark H. Wood]

On Sat, 12 May 2001, Alan Cox wrote:
> > Can somebody explain the use of ENOIOCTLCMD? There are order of 170
> > uses in the kernel, but I don't see any guidelines for that use (nor
> > what prevents it from being seen by user programs).
>
> It should never be seen by apps. If it can be then it is wrong code.
> Basically you use it in things like
>
>
>
> 	int err = dev->ioctlfunc(dev, op, arg);
> 	if( err != -ENOIOCTLCMD)
> 		return err;
>
> 	/* Driver specific code does not support this ioctl */
>
> 	switch(op)
> 	{
>
> 			...
> 		default:
> 			return -ENOTTY;
> 	}
>
> Its a way of passing back 'you handle it'

Okay, but another way of looking at it is as an instance of the classic
joke:

Husband:  What have I done wrong this time?
Wife:     If you don't know, I'm not going to tell you!

IOW instead of getting back "this file doesn't know what that IOCTL
means", you get "error somewhere".  It certainly would be nice to know
*which* parameter was invalid and *why* it was invalid.  Changing this
would be against the lore, but I would rather throw away excess
information than never have received it in the first place. *sigh*

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Make a good day.

Re: ENOIOCTLCMD?

[Jonathan Lundell]

At 12:16 PM +0100 2001-05-12, Alan Cox wrote:
>  > Can somebody explain the use of ENOIOCTLCMD? There are order of 170
>>  uses in the kernel, but I don't see any guidelines for that use (nor
>>  what prevents it from being seen by user programs).
>
>It should never be seen by apps. If it can be then it is wrong code.
>Basically you use it in things like

I was surmising something like that, but in that case aren't 
ENOIOCTLCMD and ENOTTY redundant? That is, could not every occurrence 
of ENOIOCTLCMD be replaced by ENOTTY with no change in function? 
That's what's confusing me: why the distinction? It's true that the 
current scheme allows the dev->ioctlfunc() call below to force ENOTTY 
to be returned, bypassing the switch, but presumably that's not what 
one wants.

>	int err = dev->ioctlfunc(dev, op, arg);
>	if( err != -ENOIOCTLCMD)
>		return err;
>
>	/* Driver specific code does not support this ioctl */
>
>	switch(op)
>	{
>
>			...
>		default:
>			return -ENOTTY;
>	}
>
>Its a way of passing back 'you handle it'
>-
>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/


-- 
/Jonathan Lundell.

Re: ENOIOCTLCMD?

[Alan Cox]

> That's what's confusing me: why the distinction? It's true that the 
> current scheme allows the dev->ioctlfunc() call below to force ENOTTY 
> to be returned, bypassing the switch, but presumably that's not what 
> one wants.

It allows driver specific code to override generic code, including by reporting
that a given feature is not available/appropriate.

Alan

Re: ENOIOCTLCMD?

[Shane Wegner]

On Sat, May 12, 2001 at 12:16:09PM +0100, Alan Cox wrote:
> > Can somebody explain the use of ENOIOCTLCMD? There are order of 170 
> > uses in the kernel, but I don't see any guidelines for that use (nor 
> > what prevents it from being seen by user programs).
> 
> It should never be seen by apps. If it can be then it is wrong code.
> Basically you use it in things like
> 
> 
> 
> 	int err = dev->ioctlfunc(dev, op, arg);
> 	if( err != -ENOIOCTLCMD)
> 		return err;
> 
> 	/* Driver specific code does not support this ioctl */

I noticed this return coming out of the watchdog driver a
while ago when I was playing with it.  I have taken a quick
look and it seems a few drivers do return this directly to
userspace.  I'm not sure if this is complete but ...

diff -ur linux-2.4.4-ac8/drivers/block/swim3.c linux/drivers/block/swim3.c
--- linux-2.4.4-ac8/drivers/block/swim3.c	Sat May 12 14:59:44 2001
+++ linux/drivers/block/swim3.c	Sat May 12 15:22:30 2001
@@ -848,7 +848,7 @@
 				   sizeof(struct floppy_struct));
 		return err;
 	}
-	return -ENOIOCTLCMD;
+	return -ENOTTY;
 }
 
 static int floppy_open(struct inode *inode, struct file *filp)
diff -ur linux-2.4.4-ac8/drivers/block/swim_iop.c linux/drivers/block/swim_iop.c
--- linux-2.4.4-ac8/drivers/block/swim_iop.c	Wed Feb 16 10:56:45 2000
+++ linux/drivers/block/swim_iop.c	Sat May 12 15:23:12 2001
@@ -363,7 +363,7 @@
 				   sizeof(struct floppy_struct));
 		return err;
 	}
-	return -ENOIOCTLCMD;
+	return -ENOTTY;
 }
 
 static int floppy_open(struct inode *inode, struct file *filp)
diff -ur linux-2.4.4-ac8/drivers/char/acquirewdt.c linux/drivers/char/acquirewdt.c
--- linux-2.4.4-ac8/drivers/char/acquirewdt.c	Fri Feb  9 11:30:22 2001
+++ linux/drivers/char/acquirewdt.c	Sat May 12 15:14:49 2001
@@ -110,7 +110,7 @@
 	  break;
 
 	default:
-	  return -ENOIOCTLCMD;
+	  return -ENOTTY;
 	}
 	return 0;
 }
diff -ur linux-2.4.4-ac8/drivers/char/advantechwdt.c linux/drivers/char/advantechwdt.c
--- linux-2.4.4-ac8/drivers/char/advantechwdt.c	Tue Mar  6 19:44:34 2001
+++ linux/drivers/char/advantechwdt.c	Sat May 12 15:15:58 2001
@@ -120,7 +120,7 @@
 	  break;
 
 	default:
-	  return -ENOIOCTLCMD;
+	  return -ENOTTY;
 	}
 	return 0;
 }
diff -ur linux-2.4.4-ac8/drivers/char/i810-tco.c linux/drivers/char/i810-tco.c
--- linux-2.4.4-ac8/drivers/char/i810-tco.c	Fri Dec 29 14:35:47 2000
+++ linux/drivers/char/i810-tco.c	Sat May 12 15:02:47 2001
@@ -213,7 +213,7 @@
 	};
 	switch (cmd) {
 	default:
-		return -ENOIOCTLCMD;
+		return -ENOTTY;
 	case WDIOC_GETSUPPORT:
 		if (copy_to_user
 		    ((struct watchdog_info *) arg, &ident, sizeof (ident)))
diff -ur linux-2.4.4-ac8/drivers/char/machzwd.c linux/drivers/char/machzwd.c
--- linux-2.4.4-ac8/drivers/char/machzwd.c	Thu Apr 12 12:16:35 2001
+++ linux/drivers/char/machzwd.c	Sat May 12 15:09:42 2001
@@ -357,7 +357,7 @@
 			break;
 
 		default:
-			return -ENOIOCTLCMD;
+			return -ENOTTY;
 	}
 
 	return 0;
diff -ur linux-2.4.4-ac8/drivers/char/mixcomwd.c linux/drivers/char/mixcomwd.c
--- linux-2.4.4-ac8/drivers/char/mixcomwd.c	Sun Dec  3 17:45:21 2000
+++ linux/drivers/char/mixcomwd.c	Sat May 12 15:15:18 2001
@@ -165,7 +165,7 @@
 			mixcomwd_ping();
 			break;
 		default:
-			return -ENOIOCTLCMD;
+			return -ENOTTY;
 	}
 	return 0;
 }
diff -ur linux-2.4.4-ac8/drivers/char/pc110pad.c linux/drivers/char/pc110pad.c
--- linux-2.4.4-ac8/drivers/char/pc110pad.c	Sun Feb  4 10:05:29 2001
+++ linux/drivers/char/pc110pad.c	Sat May 12 15:13:26 2001
@@ -766,7 +766,7 @@
 		current_params.tap_interval	= new.tap_interval;
 		return 0;
 	}
-	return -ENOIOCTLCMD;
+	return -ENOTTY;
 }
 
 
diff -ur linux-2.4.4-ac8/drivers/char/pcwd.c linux/drivers/char/pcwd.c
--- linux-2.4.4-ac8/drivers/char/pcwd.c	Fri Apr  6 10:42:55 2001
+++ linux/drivers/char/pcwd.c	Sat May 12 15:03:07 2001
@@ -247,7 +247,7 @@
 
 	switch(cmd) {
 	default:
-		return -ENOIOCTLCMD;
+		return -ENOTTY;
 
 	case WDIOC_GETSUPPORT:
 		i = copy_to_user((void*)arg, &ident, sizeof(ident));
diff -ur linux-2.4.4-ac8/drivers/char/sbc60xxwdt.c linux/drivers/char/sbc60xxwdt.c
--- linux-2.4.4-ac8/drivers/char/sbc60xxwdt.c	Fri Feb  9 11:30:22 2001
+++ linux/drivers/char/sbc60xxwdt.c	Sat May 12 15:10:46 2001
@@ -241,7 +241,7 @@
 	switch(cmd)
 	{
 		default:
-			return -ENOIOCTLCMD;
+			return -ENOTTY;
 		case WDIOC_GETSUPPORT:
 			return copy_to_user((struct watchdog_info *)arg, &ident, sizeof(ident))?-EFAULT:0;
 		case WDIOC_KEEPALIVE:
diff -ur linux-2.4.4-ac8/drivers/char/softdog.c linux/drivers/char/softdog.c
--- linux-2.4.4-ac8/drivers/char/softdog.c	Tue Feb 13 14:13:43 2001
+++ linux/drivers/char/softdog.c	Sat May 12 15:00:53 2001
@@ -132,7 +132,7 @@
 	};
 	switch (cmd) {
 		default:
-			return -ENOIOCTLCMD;
+			return -ENOTTY;
 		case WDIOC_GETSUPPORT:
 			if(copy_to_user((struct watchdog_info *)arg, &ident, sizeof(ident)))
 				return -EFAULT;
diff -ur linux-2.4.4-ac8/drivers/char/wdt.c linux/drivers/char/wdt.c
--- linux-2.4.4-ac8/drivers/char/wdt.c	Fri Feb  9 11:30:22 2001
+++ linux/drivers/char/wdt.c	Sat May 12 15:06:40 2001
@@ -311,7 +311,7 @@
 	switch(cmd)
 	{
 		default:
-			return -ENOIOCTLCMD;
+			return -ENOTTY;
 		case WDIOC_GETSUPPORT:
 			return copy_to_user((struct watchdog_info *)arg, &ident, sizeof(ident))?-EFAULT:0;
 
diff -ur linux-2.4.4-ac8/drivers/char/wdt285.c linux/drivers/char/wdt285.c
--- linux-2.4.4-ac8/drivers/char/wdt285.c	Mon Oct 16 12:58:51 2000
+++ linux/drivers/char/wdt285.c	Sat May 12 15:00:53 2001
@@ -136,7 +136,7 @@
 	switch(cmd)
 	{
 		default:
-			return -ENOIOCTLCMD;
+			return -ENOTTY;
 		case WDIOC_GETSUPPORT:
 			i = verify_area(VERIFY_WRITE, (void*) arg, sizeof(struct watchdog_info));
 			if (i)
diff -ur linux-2.4.4-ac8/drivers/char/wdt_pci.c linux/drivers/char/wdt_pci.c
--- linux-2.4.4-ac8/drivers/char/wdt_pci.c	Fri Feb  9 11:30:22 2001
+++ linux/drivers/char/wdt_pci.c	Sat May 12 15:00:53 2001
@@ -327,7 +327,7 @@
 	switch(cmd)
 	{
 		default:
-			return -ENOIOCTLCMD;
+			return -ENOTTY;
 		case WDIOC_GETSUPPORT:
 			return copy_to_user((struct watchdog_info *)arg, &ident, sizeof(ident))?-EFAULT:0;
 


-- 
Shane Wegner: shane@cm.nu
              http://www.cm.nu/~shane/
PGP:          1024D/FFE3035D
              A0ED DAC4 77EC D674 5487
              5B5C 4F89 9A4E FFE3 035D

Re: ENOIOCTLCMD?

[Jonathan Lundell]

At 5:43 PM +0100 2001-05-12, Alan Cox wrote:
>  > That's what's confusing me: why the distinction? It's true that the
>>  current scheme allows the dev->ioctlfunc() call below to force ENOTTY
>>  to be returned, bypassing the switch, but presumably that's not what
>>  one wants.
>
>It allows driver specific code to override generic code, including 
>by reporting
>that a given feature is not available/appropriate.
>
>Alan

What I was arguing (conceptually) is that something like

#define ENOIOCTLCMD ENOTTY

or preferably but more invasively s/ENOIOCTLCMD/ENOTTY/ (mutatis mutandis)

would result in no loss of function. I assert that ENOIOCTLCMD is 
redundant, pending a specific counterexample.
-- 
/Jonathan Lundell.

Re: ENOIOCTLCMD?

[Jonathan Lundell]

At 3:27 PM -0700 2001-05-12, Shane Wegner wrote:
>  >	int err = dev->ioctlfunc(dev, op, arg);
>>	if( err != -ENOIOCTLCMD)
>>		return err;
>>
>>	/* Driver specific code does not support this ioctl */
>
>I noticed this return coming out of the watchdog driver a
>while ago when I was playing with it.  I have taken a quick
>look and it seems a few drivers do return this directly to
>userspace.  I'm not sure if this is complete but ...

Can't this be handled in sys_ioctl()? At the very end, replace

out:
	return error;

with

out:
	return (error == -ENOIOCTLCMD) ? -ENOTTY : error;


>diff -ur linux-2.4.4-ac8/drivers/block/swim3.c linux/drivers/block/swim3.c
>--- linux-2.4.4-ac8/drivers/block/swim3.c	Sat May 12 14:59:44 2001
>+++ linux/drivers/block/swim3.c	Sat May 12 15:22:30 2001
>@@ -848,7 +848,7 @@
>  				   sizeof(struct floppy_struct));
>  		return err;
>  	}
>-	return -ENOIOCTLCMD;
>+	return -ENOTTY;
>  }


-- 
/Jonathan Lundell.

Re: ENOIOCTLCMD?

[Alan Cox]

> What I was arguing (conceptually) is that something like
> #define ENOIOCTLCMD ENOTTY
> or preferably but more invasively s/ENOIOCTLCMD/ENOTTY/ (mutatis mutandis)
> 
> would result in no loss of function. I assert that ENOIOCTLCMD is 
> redundant, pending a specific counterexample.

On the contrary. I can now no longer force an unsupported response when there
is a generic routine I dont wish to use

Re: ENOIOCTLCMD?

[Jonathan Lundell]

At 5:45 PM +0100 2001-05-13, Alan Cox wrote:
>  > What I was arguing (conceptually) is that something like
>>  #define ENOIOCTLCMD ENOTTY
>>  or preferably but more invasively s/ENOIOCTLCMD/ENOTTY/ (mutatis mutandis)
>>
>>  would result in no loss of function. I assert that ENOIOCTLCMD is
>>  redundant, pending a specific counterexample.
>
>On the contrary. I can now no longer force an unsupported response when there
>is a generic routine I dont wish to use

That makes sense. Thanks.
-- 
/Jonathan Lundell.