On Sun, Jul 09, 2023 at 11:52:39PM -0700, Christoph Hellwig wrote: > On Fri, Jul 07, 2023 at 08:59:03AM +0800, Ming Lei wrote: > > > let's clearly state so. But then, I still not understand why these need > > > a different naming pattern using the "__UBLK" prefix... > > > > I think __UBLK just meant we don't suggest userspace to use it directly, > > since the added macros are just for making ranges for DRV_IN and DRV_OUT, > > so we can check command direction easily be using this start/end info in > > both sides. > > Folks, please stop coupling a uapi (or on-disk protocol) too tightly > to Linux internals. Think of what makes sense as a communication > protocol, not what is an internal kernel interface. > > REPORT_ZONES is a sensible command, and supported in ATA/SCSI/NVMe in > one way or another. In Linux it is a synchronous method call right now > for one reason or another, and most implementation map it to a > passthrough command - be that the actual protocol command or something > internal for virtio. > > So for ublk this is just another command like any other, that needs to > be defined and documented. Nothing internal or driver specific. Yes, that is exactly what we are doing. The added macros of UBLK_IO_OP_DRV_IN_START[END] are just for supporting more ublk passthrough commands, and the motivation is for running check(such as buffer direction) in two sides easily. However, I think it is just fine to delay to add it until introducing the 2nd ublk pt command. Thanks, Ming
