On Wed, Aug 24, 2022 at 2:10 AM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Aug 23, 2022 at 01:02:08PM -0400, Paul Moore wrote: > > On Tue, Aug 23, 2022 at 2:52 AM Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Mon, Aug 22, 2022 at 05:21:19PM -0400, Paul Moore wrote: > > > > This patch adds support for the io_uring command pass through, aka > > > > IORING_OP_URING_CMD, to the /dev/null driver. As with all of the > > > > /dev/null functionality, the implementation is just a simple sink > > > > where commands go to die, but it should be useful for developers who > > > > need a simple IORING_OP_URING_CMD test device that doesn't require > > > > any special hardware. > > > > > > Also, shouldn't you document this somewhere? > > > > > > At least in the code itself saying "this is here so that /dev/null works > > > as a io_uring sink" or something like that? Otherwise it just looks > > > like it does nothing at all. > > > > What about read_null() and write_null()? I can definitely add a > > comment (there is no /dev/null documentation in the kernel source tree > > that I can see), but there is clearly precedence for /dev/null having > > "do nothing" file_operations functions. > > Yes, they should "do nothing". Right, I don't think anyone was disputing that. You were asking for a comment for the new function that effectively says "this function does nothing", which seems a little silly given the simplicity of the function, the name, and the context of it all. > write_null() does report that it > consumed everything, why doesn't this function have to also do that? Because a file write (file_operations->write) and a IORING_OP_URING_CMD (file_operations->uring_cmd) are fundamentally different operations; uring_cmd_null() returns 0, which is the success return code for this file op (not to mention a significant number of kernel functions that return an int). -- paul-moore.com
