Re: [LSF/MM/BPF TOPIC] configfd as a replacement for both ioctls and fsconfig

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux