ioctl() forever? [LWN.net]

ioctl() forever?

Posted Jun 8, 2022 18:41 UTC (Wed) by atnot (guest, #124910)
In reply to: ioctl() forever? by tau
Parent article: ioctl() forever?

> There is also a tendency to crowbar a kernel's API semantics into the language of a virtual filesystem, with virtual directories containing virtual text files

I don't remember who said this, but the lesson should not have been "everything is a file" being good, but "everything is a file descriptor" being good. There is great value in having a unified way of representing kernel resources and associated access capabilities, one that can easily be shared between subsystems and passed between processes. But the part where you usually need to obtain those file descriptors by painfully funneling everything through hundreds of snprintf() and open() calls on hardcoded paths isn't actually that valuable. In fact it often only undermines those valuable properties.

to post comments

ioctl() forever?

Posted Jun 9, 2022 0:53 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

Meh, snprintf isn't the kernel's fault, it's C's fault for being terrible at finagling strings. Stringly-typed interfaces are bad because they are difficult or impossible to validate, not because snprintf is painful.

ioctl() forever?

Posted Jun 9, 2022 1:35 UTC (Thu) by atnot (guest, #124910) [Link]

This wasn't at all meant to be a dig at snprintf(), feel free to insert your preferred mechanism. I just don't think string formatting is something that should be regularly involved at the very core of OS APIs at all, even if C's string handling wasn't as uniquely terrible as it is. Although that fact doesn't help of course.