On Tue, 2022-03-01 at 08:53 -0800, Luis Chamberlain wrote: > On Tue, Mar 01, 2022 at 11:47:56AM -0500, James Bottomley wrote: > > On Mon, 2022-02-28 at 16:45 -0800, Luis Chamberlain wrote: > > > On Tue, Feb 01, 2022 at 02:13:13PM +0000, David Howells wrote: > > > > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > If the ioctl debate goes against ioctls, I think configfd > > > > > would > > > > > present > > > > > a more palatable alternative to netlink everywhere. > > > > > > > > It'd be nice to be able to set up a 'configuration transaction' > > > > and > > > > then do a > > > > commit to apply it all in one go. > > > > > > Can't io-uring cmd effort help here? > > > > What io-uring cmd effort? > > The file operations version is the latest posted effort: > > https://lore.kernel.org/linux-nvme/20210317221027.366780-1-axboe@xxxxxxxxx/ Oh, right ... I'm afraid for storage if it hasn't been across linux- block or linux-scsi, I likely won't have seen it. However, reading the thread, it really does look like the added file operation int (*uring_cmd)(struct io_uring_cmd *, enum io_uring_cmd_flags); Is pretty similar to an async ioctl as Christoph said. > > The one to add nvme completions? > > Um, I would not call it that at all, but rather nvme passthrough. But > yes that is possible. But so are many other things, not just ioctls, > which is why I've been suggesting I think it does a disservice to the > efforto just say its useful for ioctl over io-uring. Anything with > a file_operations can tackle on cmd suport using io-uring as a > train. It looks fairly similar given the iouring syscalls are on an fd except that the structure above hash to be defined and becomes an ABI. Since they configfd uses typed key value pairs, i'd argue it's more generic and introspectable. James
