VBoxGuest IOCTL codes and structures.

The range 0..15 is for basic driver communication. The range 16..31 is for HGCM communcation. The range 32..47 is reserved for future use. The range 48..63 is for OS specific communcation. The 7th bit is reserved for future hacks. The 8th bit is reserved for distinguishing between 32-bit and 64-bit processes in future 64-bit guest additions.

While windows IOCTL function number has to start at 2048 and stop at 4096 there never was any need to do this for everyone. A simple ((Function) | 0x800) would have sufficed. On Linux we're now intruding upon the type field. Fortunately this hasn't caused any trouble because the FILE_DEVICE_UNKNOWN value was set to 0x22 (if it were 0x2C it would not have worked soo smoothly). The situation would've been the same for *BSD and Darwin since they seems to share common _IOC() heritage.

However, on good old OS/2 we only have 8-bit handy for the function number. The result from using the old IOCTL function numbers her would've been overlapping between the two ranges.

To fix this problem and get rid of all the unnecessary windowsy crap that I bet was copied from my SUPDRVIOC.h once upon a time (although the concept of prefixing macros with the purpose of avoid clashes with system stuff and to indicate exactly how owns them seems to have been lost somewhere along the way), I've introduced a VBOXGUEST_IOCTL_CODE for defining generic IN/OUT IOCtls on new ports of the additions.

Remarks:

When creating new IOCtl interfaces keep in mind that not all OSes supports reporting back the output size. (This got messed up a little bit in VBoxDrv.)

The request size is also a little bit tricky as it's passed as part of the request code on unix. The size field is 14 bits on Linux, 12 bits on *BSD, 13 bits Darwin, and 8-bits on Solaris. All the BSDs and Darwin kernels will make use of the size field, while Linux and Solaris will not. We're of course using the size to validate and/or map/lock the request, so it has to be valid.

For Solaris we will have to do something special though, 255 isn't sufficent for all we need. A 4KB restriction (BSD) is probably not too problematic (yet) as a general one.

More info can be found in SUPDRVIOC.h and related sources.

Remarks:

If adding interfaces that only has input or only has output, some new macros needs to be created so the most efficient IOCtl data buffering method can be used.