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("a_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
