On Tue, Sep 7, 2021 at 1:17 PM Christoph Hellwig <hch@xxxxxx> wrote:
>
> Looking at this in isolation:
>
> - no need to also implement the legacy non-64 passthrough interface
> - no need to overlay the block_uring_cmd structure as that makes a
> complete mess
>
> Below is an untested patch to fix that up a bit.
Thanks for taking a look and cleaning that up. Looks a lot better.
> A few other notes:
>
> - I suspect the ioctl_cmd really should move into the core using_cmd
> infrastructure
Yes, that seems possible by creating that field outside by combining
"op" and "unused" below.
+struct io_uring_cmd {
+ struct file *file;
+ __u16 op;
+ __u16 unused;
+ __u32 len;
+ __u64 pdu[5]; /* 40 bytes available inline for free use */
+};
> - please stick to the naming of the file operation instead of using
> something different. That being said async_ioctl seems better
> fitting than uring_cmd
Got it.
> - that whole mix of user space interface and internal data in the
> ->pdu field is a mess. What is the problem with deferring the
> request freeing into the user context, which would clean up
> quite a bit of that, especially if io_uring_cmd grows a private
> field.
That mix isn't great but the attempt was to save the allocation.
And I was not very sure if it'd be fine to defer freeing the request
until task-work fires up.
Even if we take that route, we would still need a place to store bio
pointer (hopefully meta pointer can be extracted out of bio).
Do you see it differently?
Thanks,
--
Kanchan
