Personally I find the heavy use of ioctls in modern Linux APIs bit distasteful. Sure, its pragmatic and easy, but it really feels abusing the UNIX mantra of "everything is a file" when the only operation you can do for that "file" is some specific ioctls. I first noticed this in the very nice KVM article that ran on LWN few years back, and now again here. I really wish there was some more structured way of talking to the kernel, but I can understand that introducing a ton of new syscalls probably is not practical.
Nitpick: DRM files also support mmap(), which is how you map video memory into user space.
To your overall point though: do you think there's something better?
The operations required by user-mode drivers and APIs just don't map well to file operations. On the other hand, creating dedicated syscalls for graphics isn't very attractive either, because many of the ioctls are quite hardware-specific.
Using ioctls is a pragmatic solution, and I doubt you can really come up with something much better, though I'd be interested in being proven wrong.
I think something like bus1 might be neat, but admittedly I haven't thought that out very throughly. Of course bus1 is not even in mainline yet, and ioctl apis have been around for decades
> I really wish there was some more structured way of talking to the kernel
There's netlink. It's "more structured", in that it has a lot more structures.
Modules of common subsystems already support the same ioctl structs where this makes sense. Any mechanism replacing ioctls would only change the way you call it, it cannot reduce the inherent differences between modules. Well, one could use D-Bus or some generic property / key-value system, but this would only be generic on the surface.
The "Everything is a file in Unix" principle really hasn't been true since 1983 when Berkeley sockets were introduced. Network interfaces are neither files nor sockets. There are plenty of Linux concepts, which are yet something else.
Just as a side node to your ioctl criticism, I don't say ioctls are great.
GPU drivers are different. Basically, Windows have Direct3D already in the kernel, exposing relatively large API surface for the userland half of the driver.
They have come up with plenty more ways to talk to the kernel.
Just look at the absolute abortion that is "netlink". Very deeply nested structures with self-referencing pointers and sizeofs everywhere. You are looking at 300 LoC for the most trivial operations unless you want to use a shitty (like extfs tools shitty) library.
I actually prefer the ioctl, it keeps the insanity in check of these structure astronauts that gave us netlink.
Yea, I think ioctl is probably the most elegant solution. The fact that hardware has a wide-variation in properties, requests, etc. mean some part of the interface is going to be inelegant and case dependent. ioctl at least puts all that variation behind a single system call.
This interesting article also reminded me of another HN story (comment really) [1] about Carmack's interest in providing Plan 9 with great interactive graphics. It's IMO a great pity they didn't consider his input more seriously.
