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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Sep 08, 2026 at 12:51:08PM +0100, Richard W.M. Jones wrote:
> 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.

Up to you. I actually take it back about trying to cut out the
last byte - no driver seems to combine status and data, let's just
make data a power of 2 in size.


> > 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?

Yes. I am just saying there are drivers with VIRTIO_BLK_F_LONG_ID
that see the long id or without that see short one.
No one checks both so there is no need to constrain how
they are related.

> 
> > 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.

I like that.

> > > +
> > > +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