Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

On Tue, Feb 01, 2022 at 02:20:48PM +0100, Christian Brauner wrote:

On Mon, Jan 31, 2022 at 05:33:29PM -0800, Luis Chamberlain wrote:

quoted

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].
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.

Possible issues? Kernels without CONFIG_NET. Is that a deal breaker?
We already have a few filesystems with their own generic netlink
families, so not sure if this is a good argument against this.

mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family fs
fs/cifs/netlink.c:      ret = genl_register_family(&cifs_genl_family);
fs/dlm/netlink.c:       return genl_register_family(&family);
fs/ksmbd/transport_ipc.c:       ret = genl_register_family(&ksmbd_genl_family);
fs/quota/netlink.c:     if (genl_register_family(&quota_genl_family) != 0)
mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family drivers/block
drivers/block/nbd.c:    if (genl_register_family(&nbd_genl_family)) {

Are there other reasons to *not* use generic netlink for new features?
For folks with experience using generic netlink on the block layer and
their own fs, any issues or pain points observed so far?

Netlink is a giant pain to use for userspace tbh. ioctl()s aren't great
but they are way easier to add and use.

We trade ease-of use for sloppiness. We must accept that at least.

  Luis