On Mon, 2022-01-31 at 17:33 -0800, Luis Chamberlain wrote: > It would seem we keep tacking on things with ioctls for the block > layer and filesystems. Even for new trendy things like io_uring [0]. And many systems besides ... we're also adding new ioctls for things like containers. However, could I just ask why you object to ioctls? I agree, like any drug, overuse leads to huge problems. However, there are medicinal use cases where they actually save a huge amount of pain. So I think as long as we're careful we can still continue using them. What is the issue? Just the non-introspectability of the data from the perspective of tools like seccomp? > For a few years I have found this odd, and have slowly started > asking folks why we don't consider alternatives like a generic > netlink family. I've at least been told that this is desirable > but no one has worked on it. *If* we do want this I think we just > not only need to commit to do this, but also provide a target. LSFMM > seems like a good place to do this. It's not just netlink. We have a huge plethora of interfaces claiming to replace the need for ioctl as a means for exchanging information between a multiplexor and an in-kernel set of receivers. The latest one I noticed would be fsconfig, although that is filesystem specific (but could be made more generic). And, of course, configfs was supposed to be another generic but introspectable configuration exchange system. We're quite good at coming up with ioctl replacement, however when we do they don't seem to be as durable. I think we should really examine what we think the problem is in detail before even starting to propose a solution. James
