A shortened version of this topic was originally sent for LSF/MM 2020 which didn't happen due to the pandemic: https://lore.kernel.org/all/1581781497.3847.5.camel@xxxxxxxxxxxxxxxxxxxxx/ However, now replacing ioctls is on the table: https://lore.kernel.org/all/20220201013329.ofxhm4qingvddqhu@garbanzo/ as I've already stated in that thread, I think, used sparingly, ioctls are fit for purpose and shouldn't be replaced and I'd definitely like to argue for that position. However, assuming that people would like to consider alternatives, I'd like to propose configfd. It was originally proposed as a configuration mechanism for bind mounts that was a more general replacement for fsconfig (which can only configure filesystems with superblocks) and was going to be used by shiftfs. However, since shiftfs functionality was done a different way, configfd has languished, although the patches are here: https://lore.kernel.org/all/20200215153609.23797-1-James.Bottomley@xxxxxxxxxxxxxxxxxxxxx/ The point, though, is that configfd can configure pretty much anything; it wouldn't just be limited to filesystem objects. It takes the fsconfig idea of using a file descriptor to carry configuration information, which could be built up over many config calls and makes it general enough to apply to anything. One of the ideas of configfd is that the data could be made fully introspectable ... as in not just per item description, but the ability to get from the receiver what it is expecting in terms of configuration options (this part was an idea not present in the above patch series). If the ioctl debate goes against ioctls, I think configfd would present a more palatable alternative to netlink everywhere. James
