3 ms·

According to the tweet linked above using device local ioctls are better if you’re not upstreaming.

• _hilro 5y ago
  > using device local ioctls are better Sure but is that not because the tweet concerns a NAS and the ioctls would relate to an actual device(the storage devices)? Would 'device local ioctls' work in the blog post scenario where it's just a general purpose process attribute?: > ..we will assign every process a weight
  • lokedhs 5y ago
    Yes. A device doesn't even need to support reading and writing. The driver simply registers some name in /dev and the userspace code opens it and does ioctl. You could also register a name under /proc. There is really no reason to have custom system calls.
    • _hilro 5y ago
      Hmm, interesting thanks. Given the name IO..ctl, is this unintended or unavoidable behaviour?
      • phendrenad2 5y ago
        The name probably originally came from controlling i/o ports and devices at a meta level. But they're just a mechanism for sending a chunk of data to the kernel, and if something in the kernel is watching that path (e.g. /sys/foobar) then it'll be in invoked. This is apparently how audio works on Linux. The kernel abstracts over sound devices, and provides a sort of "virtual device" at /proc/asound (https://www.kernel.org/doc/html/latest/sound/designs/procfile.html https://www.kernel.org/doc/html/latest/sound/designs/procfil...)