On Tue, Feb 01, 2022 at 07:56:19AM -0500, James Bottomley wrote: > 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. Getting to the point we are comparing use of ioctls with drugs is a good indication we probably haven't given much thought to our sloppy dependency on them. > What is the issue? Just the non-introspectability of the data from the > perspective of tools like seccomp? That's one. The opaque nature is silly. I can run blktrace on tons of my /dev/ files and do *interesting* stupid things. This just seems plain wrong... > > 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. Yes and with io-uring cmd coming into my radar, and folks wanting to do things like io-uring for ioctls get's me thinking this is just going to get sloppier. I admit I like the idea of io-uring cmd for ioctls but I would have to think that's our future. > The latest > one I noticed would be fsconfig, although that is filesystem specific > (but could be made more generic). Thanks I'll check that out. > 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. Sure, and evaluate what solutions already exist. Alrighty, so as an example... I recall when we were working on trying to avoid doing the stupid ioctl mess with wireless. Yes it made sense to use generic netlink, but the results are quite impressive if you ask me in terms of clarify and documentation: include/uapi/linux/nl80211.h So I can't be doing stupid things like sending a NL80211_CMD_GET_BEACON command to an ethernet device, for instance. But that's not just it. The clear specification of data types is great. ioctls for new features for fileystems / the block layer just makes them seem almost cavemen like. And that we don't stop and seem to have a clear north star for an alternative does get me to ask do we really want an alternative and if so so well let's get to it. Luis
