This is a good discussion to have On Sat, Feb 5, 2022 at 6:02 AM James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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 > > -- Thanks, Steve
