On Thu, Jun 22, 2023 at 07:03:04PM +0200, Greg Kroah-Hartman wrote: > On Thu, Jun 22, 2023 at 09:38:15AM -0700, Breno Leitao wrote: > > On Thu, Jun 22, 2023 at 06:10:00PM +0200, Greg Kroah-Hartman wrote: > > > On Thu, Jun 22, 2023 at 08:02:37AM -0700, Breno Leitao wrote: > > > > On Thu, Jun 22, 2023 at 07:20:48AM +0200, Greg Kroah-Hartman wrote: > > > > > On Wed, Jun 21, 2023 at 04:21:26PM -0700, Breno Leitao wrote: > > > > > > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst > > > > > > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst > > > > > > @@ -361,6 +361,7 @@ Code Seq# Include File Comments > > > > > > 0xCB 00-1F CBM serial IEC bus in development: > > > > > > <mailto:michael.klein@xxxxxxxxxxxxxxxxxxxx> > > > > > > 0xCC 00-0F drivers/misc/ibmvmc.h pseries VMC driver > > > > > > +0xCC A0-BF uapi/linux/io_uring.h io_uring cmd subsystem > > > > > > > > > > This change is nice, but not totally related to this specific one, > > > > > shouldn't it be separate? > > > > > > > > This is related to this patch, since I am using it below, in the > > > > following part: > > > > > > > > +#define SOCKET_URING_OP_SIOCINQ _IOR(0xcc, 0xa0, int) > > > > +#define SOCKET_URING_OP_SIOCOUTQ _IOR(0xcc, 0xa1, int) > > > > > > > > Should I have a different patch, even if they are related? > > > > > > Yes, as you are not using the 0xa2-0xbf range that you just carved out > > > here, right? Where did those numbers come from? > > > > Correct. For now we are just using 0xa0 and 0xa1, and eventually we > > might need more ioctls numbers. > > > > I got these numbers finding a unused block and having some room for > > expansion, as suggested by Documentation/userspace-api/ioctl/ioctl-number.rst, > > that says: > > > > If you are writing a driver for a new device and need a letter, pick an > > unused block with enough room for expansion: 32 to 256 ioctl commands. > > So is this the first io_uring ioctl? If so, why is this an ioctl and > not just a "normal" io_uring call? This is a way to pass a generic command to file. This is not a ioctl per se (not called through ioctl). I am leveraging the ioctl to embedded the "direction" and "size" information in the command itself. I can defintely do something as the following, if it is a better implementation: #define SOCKET_URING_OP_SIOCINQ 0 #define SOCKET_URING_OP_SIOCOUTQ 1