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
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
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
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
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?
is used to connect to the kernel module (as nbd.ko does
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
is used to connect to the kernel module (as nbd.ko does not expect
them), but there is no harm in all other clients requesting them.
Extended headers are not
