Re: [PATCH v3 1/1] device-types/blk/description.tex: Allow longer device IDs to be returned

["Richard W.M. Jones" <rjones@redhat.com>]

On Tue, Sep 08, 2026 at 06:57:08AM -0400, Michael S. Tsirkin wrote:
> Thanks for the patch! Yes something to improve:
> 
> On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> >  VIRTIO_BLK_T_GET_ID requests fetch the device ID string from the device into
> > -\field{data}.  The device ID string is a NUL-padded ASCII string up to 20 bytes
> > -long.  If the string is 20 bytes long then there is no NUL terminator.
> > +\field{data}.  The device ID string is an ASCII string which can be
> > +up to 247 bytes long.
> 
> Judging by the below, it does not have to be ASCII? just a nul
> terminated string?
> 
> 
> 247 is just a very weird limit.
> So we get another
> arbitrary number drivers need to worry about. Ugh.
> I just don't get all the references
> to scsi vpd or whatever. It's your motivation I get that
> but we should not set policy.
> 
> Let's just simply limit the string to  255 bytes and
> make data 255 bytes too?

I wonder actually if 128 is better.  It fits within the Windows limit
and it doesn't hurt for Linux either because of NAME_MAX limitations
that you would encounter with udev.

> Then with the status byte the write buffer fits in a 256 pcie packet.
> 
> Maybe others feel differently.
> 
> > +
> > +If VIRTIO_BLK_F_LONG_ID was not negotiated, VIRTIO_BLK_T_GET_ID
> > +fetches the first 20 bytes of the device ID string.  If the ID is
> > +shorter than 20 bytes, then the response is padded with NUL bytes so
> > +its length is 20 bytes.  (Note that if the ID is 20 bytes or longer,
> > +this means the response will not be NUL terminated.)
> 
> But the driver can not both negotiate and not negotiate
> VIRTIO_BLK_F_LONG_ID.

Interesting .. so I think I misunderstood how feature negotiation
works.  I _thought_ that the driver sends back features it
understands, via the features array:

https://github.com/torvalds/linux/blob/28924df2a08f440c73991b83028032c901de2ae4/drivers/block/virtio_blk.c#L1669

and therefore the host side can see if the driver supports
VIRTIO_BLK_F_LONG_ID.  Is that not how it works?

> So what does this requirement that the two configs share
> a prefix buy us, practically?
> 
> Why don't we just say that the ID is up to either 20 bytes or
> 255 bytes depending on the feature negotiation?

We can just drop the "first" language.

> > +
> > +If VIRTIO_BLK_F_LONG_ID was negotiated, VIRTIO_BLK_T_GET_ID fetches
> > +the complete device ID string.  The response is always 248 bytes long,
> > +padded to this length with NUL bytes.  Since the longest permitted
> > +device ID string is 247 bytes, the response is NUL terminated.
> 
> Let's just handle short and long forms consistently please.
> If the string fills all of data then it is not terminated. end of story.
> 
> All the subtle differences are just a source for confusion.  Can we not
> define something like "maximum ID length" and then use it everywhere,
> instead of all the duplication?

Sure.

> > +
> > +Although 247 byte device ID strings are allowed, there may be
> > +interoperability problems if strings longer than 128 bytes are used.
> 
> I think you mean 127? so it's 128 with the NUL.
> 
> > +It is also advisable to use only 7 bit ASCII characters.
> 
> ASCII == 7 bit. Maybe you mean printable characters?
> 
> 
> Pls add both these recommendations in the conformance section.

OK.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit