Re: [PATCH v3 12/14] nbd/client: Request extended headers during negotiation

[Vladimir Sementsov-Ogievskiy]

On 31.05.23 23:26, Eric Blake wrote:
> On Wed, May 31, 2023 at 09:33:20PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> > On 31.05.23 20:54, Eric Blake wrote:
> > > On Wed, May 31, 2023 at 08:39:53PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> > > > On 15.05.23 22:53, Eric Blake wrote:
> > > > > All the pieces are in place for a client to finally request extended
> > > > > headers.  Note that we must not request extended headers when qemu-nbd
> > > >
> > > > why must not? It should gracefully report ENOTSUP? Or not?
> > >
> > > The kernel code does not yet know how to send extended requests; once
> > > extended mode is negotiated, sending a simple request requires the
> >
> > but how it could be negotiated if kernel doesn't support it?
>
> That's the problem.  The kernel doesn't do the negotiation, userspace

oh yes, I totally forget these mechanics

> does.  There is an ioctl for the userspace to tell the kernel what
> flags were advertised as part of the negotiation, but that does not
> include a flag for extended operation.  The kernel ONLY takes care of
> NBD_CMD_ operations, it does not do NBD_OPT_ operations.  So when
> qemu-nbd is preparing to connect to /dev/nbdN, it first has to
> negotiate in userspace, avoiding any attempt to use extended headers,
> then call the right ioctls for the kernel to take over command phase
> using the older compact headers.

> > I mean if we request extended headers during negotiation with kernel, the kernel will 
> > just say "unsupported option", isn't it?
>
> If we request extended headers in userspace before calling the ioctl
> to tell the kernel to start transmission, then the kernel's first
> command will use the compact style, which the server is not expecting,
> and while we can hope the server will hang up on the kernel, I didn't
> test what actually happens.
>
>
> > Or, in other words, I understand that kernel doesn't support it, I don't 
> > understand why you note it here. Is kernel different from other NBD server 
> > implementations which doesn't support extended requests at the moment?
>
> The kernel is an NBD client, not a server.  But if we are about to
> connect an NBD server over to the kernel for /dev/nbdN, we better make
> sure the server is not using any features the kernel doesn't support.

thanks!

--
Best regards,
Vladimir