Skip to contentSkip to conversation

procedure for creating new ioctl?

DISCUSSION Joseph Cheek 3 participants 3 messages Jun 10, 2002

lore
Share & tools
lore
#0 lore raw

hi all,

i'd like to create a new ioctl for use in my kernels [actually i already have 8-)] but want to make sure that i follow any established procedure for creating it before requesting it be included in the kernel. specifically, is there a way to ensure the ioctl number i use isn't in use by anyone else? is there a central registry?

so far i've just picked an arbitrary number:

sanfrancisco:/usr/src/linux-2.4.17/include/linux# diff -Naur kd.h{.orig,}
--- kd.h.orig   Mon Jun 10 11:08:22 2002
+++ kd.h        Thu Jun  6 16:00:33 2002
@@ -177,4 +177,6 @@
   don't reuse for the time being */
/* note: 0x4B60-0x4B6D, 0x4B70-0x4B72 used above */

+#define KDGETKEYDOWNSTATE 0x4B80 /* read kernel keydown bit */
+
#endif /* _LINUX_KD_H */

any tips, pointers appreciated.

joe

Signature · 4 lines
Joseph Cheek, CTO and Founder, Lycoris
[email protected], www.lycoris.com
Lycoris Desktop/LX: Familiar.  Powerful.  Open.
+1 425 413-9521 voice, +1 425 671-0504 fax
#1 lore raw
Quoted 21 lines · Joseph Cheek

hi all,

i'd like to create a new ioctl for use in my kernels [actually i already have 8-)] but want to make sure that i follow any established procedure for creating it before requesting it be included in the kernel.
specifically, is there a way to ensure the ioctl number i use isn't in
use by anyone else? is there a central registry?

so far i've just picked an arbitrary number:

sanfrancisco:/usr/src/linux-2.4.17/include/linux# diff -Naur kd.h{.orig,}
kd.h Thu Jun 6 16:00:33 2002 renamed from kd.h.orig Mon Jun 10 11:08:22 2002 +2 -0
@@ -177,4 +177,6 @@
    don't reuse for the time being */
 /* note: 0x4B60-0x4B6D, 0x4B70-0x4B72 used above */
 
+#define KDGETKEYDOWNSTATE      0x4B80  /* read kernel keydown bit */
+
 #endif /* _LINUX_KD_H */
Quoted 4 lines

any tips, pointers appreciated.

joe

I use SIOCDEVPRIVATE as the starting value for new ioctls:

/*
* Interface to the private device functions. User API sees this only.
*/

#define CHEK_SEEPROM   SIOCDEVPRIVATE + 0x07
#define READ_SEEPROM   SIOCDEVPRIVATE + 0x08
#define WRITE_SEEPROM  SIOCDEVPRIVATE + 0x09

I've seen this in several drivers. I think this is the way to do it so there is no interference with other ioctls.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

Windows-2000/Professional isn't.

#2 lore raw
In reply to Joseph Cheek
Quoted 5 lines · Richard B. Johnson

I use SIOCDEVPRIVATE as the starting value for new ioctls:

/*
* Interface to the private device functions. User API sees this only.
*/

Quoted 7 lines
#define CHEK_SEEPROM   SIOCDEVPRIVATE + 0x07
#define READ_SEEPROM   SIOCDEVPRIVATE + 0x08
#define WRITE_SEEPROM  SIOCDEVPRIVATE + 0x09

I've seen this in several drivers. I think this is the way to do it so there is no interference with other ioctls.

Of course there is. That means that a program accidentally running on the wrong device will get completely unexpected results because the ioctl numbers will all be some value above SIOCDEVPRIVATE.

Since each of the drivers have (mostly) their own private ioctl handling, there is less of an issue of actual ioctl number conflicts as there is an issue that ioctl numbers should be globally unique to avoid accidental side effects when running on an incorrect device.

Besides which, SIOCDEVPRIVATE is supposed to be for socket (networking) ioctls and not just random ioctl values. The comment above it also indicates this value is deprecated...

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/