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

[Luis Chamberlain <mcgrof@kernel.org>]

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?

[0] https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=nvme-passthru-wip.2&id=d11e20acbd93fbbcdaf87e73615cdac53b814eca

  Luis