Kernel compatibility : ioctl(2)

Continuing with syscalls, I would like to indicate you a modification I've done with regards to ioctl's. The thing is, I have had the need for ioctl's that return *file descriptors*, instead of standard return codes.

To distinguish them from the others, I have given them identifiers that are superior or equal to 0x80000000 (when unsigned, negative when signed). Of course, Linux will reject them, but that's fine, these are low-level OS-dependant ioctl's that aren't supposed to be compatible.

Do you have any objection or remark regarding this?

Thanks!

Emmanuel

You probably only think you have ;-)

The return from an ioctl on 32bit is going to be an unsigned 32bit value, as is a Linux file handle. So if you do

	fd = ioctl(foo);

then not only have you got an interface that isn't compliant with POSIX/SuS you also have no error reporting capability.

The expectation of ioctl is

	err = ioctl(fd, FDIOWIBBLE, &result);

now if result is a pointer to where to store one or more file handles you are sorted.

If you are going to use SuS/POSIX naming I'd really suggest sticking to the expected behaviour in the standards.

Alan

Wait, on 32 bits, no process can have 2^32 file handles, or even 2^31. Thus, since the error code is a negative value, userspace will simply do :

fd = _sys_ioctl(foo);
if (fd < 0)

	errno = -fd;

Which the libc is going to do for them anyways if they call ioctl() directly.

Also feasible.

I think this is an unproblematic extension, especially since these ioctls are only supposed to be called by low-level software shipped with the OS.

Emmanuel

Thats the excuse everyone gives for messing up standards stuff. It usually comes back to bite you later.

If it's not ioctl don't call it ioctl, have a fdoctl() or something

Alan

I see your point... Well, this looks like the most staightforward approach then. I'll go with fdoctl().

Emmanuel