The problem with ioctl is how to handle that inconvenient 
third argument.  The prototype for ioctl is:

int ioctl(int fd, int cmd, ...);

The var-args last argument can be a long, or a pointer to 
anything.  It is very much driver specific.  The Linux 
kernel itself doesn't know the type of that argument.  
Admittedly there is some type information stored in the 
ioctl cmd value (together with the data direction - in, out, 
in/out) but it doesn't help that much.  

Implementing a PHP wrapper will not be trivial.  The third 
argument of dio_ioctl() would have to be a reference to a 
PHP variable.  Structure data would have to be represented 
as binary data in strings and it would be up to the 
implementer to populate and interpret those binary strings.  
You couldn't pass in hashes/arrays or objects as DIO would 
not know what to do with them.

Personally I feel if you're going as far as wanting to drive 
ioctls from PHP you should be writing a PECL extension to do 
it.  It is my intention to implement a DIO class which 
encapsulates the current DIO posix functions so once this is 
done you could extend that class in your own extension and 
add methods that call any ioctls you need to call.

I think you're missing something.  The type and size of the 3rd argument are embedded in the value of the 2nd argument.

See the _IOC() macro, and the IOC_TYPE() and _IOC_SIZE() macros:

http://elixir.free-electrons.com/linux/v3.6/source/include/asm-generic/ioctl.h#L65

If there's enough information to marshal into/out of userspace to kernel space, then there's enough information to marshal (the blob) for a simple language wrapper.

To compose/decompose the blob, yes, some sophisticated use of pack()/unpack() would be required.

Can this request be reopened? I'm (ab-)using php as a general cli scripting language and need the cdrom ioctl calls.