我觉得：1
内核开发者可以使用宏来定义新的命令，这个命令可以避免别的预留的命令（在VFS层使用的，比如说你提到的0，1，2这些）产生冲突。
2
使用宏比使用直接的数字更容易不出错，无论是内核的开发者，还是这个设备的使用者，这个跟其他系统调用如kill，signal这些是一个道理。
3
的确你自己定义的文件，随便你写什么命令都可以，与其他类型的文件冲突也没关系，只要不与VFS层的冲突就可以了，也不需要专门定义宏。
4
还要考虑到linux不只有x86一个平台的，同一套iotcl需要跟不同的处理器兼容，直接使用数字的话在处理诸如大小端这类问题很麻烦，而且有些命令在不同的平台上值是不一样的（如_IOC_NONE在sparc上是1，而一般为0），为什么要这样取值我也不知道，详细可以研究相关的处理器架构或者ioctl代码。其实你看看这些宏的定义就清楚了。
5 最后摘抄一段源码的注释：
/* ioctl command encoding: 32 bits total, command in lower 16
bits,
5 * size of the parameter structure in the lower 14 bits of
the
6 * upper 16 bits.
7 * Encoding the size of the parameter structure in the
ioctl request
8 * is useful for catching programs compiled with old
versions
9 * and to avoid overwriting user space outside the user
buffer area.
10 * The highest 2 bits are reserved for indicating the
``access mode''.
11 * NOTE: This limits the max parameter size to 16kB -1 !
12 */
/*
5 * The original linux ioctl numbering scheme was just a
general
6 * "anything goes" setup, where more or less
random numbers were
7 * assigned. Sorry, I was clueless when I started out on
this.
8 *
9 * On the alpha, we'll try to clean it up a bit, using a
more sane
10 * ioctl numbering, and also trying to be compatible with
OSF/1 in
11 * the process. I'd like to clean it up for the i386 as
well, but
12 * it's so painful recognizing both the new and the old
numbers..
13 */
