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

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

On Sun, Sep 06, 2026 at 11:13:39AM -0400, Michael S. Tsirkin wrote:
> On Sun, Sep 06, 2026 at 03:54:44PM +0100, Richard W.M. Jones wrote:
[...]
> U also want a feature bit otherwise driver does not know if it's safe to
> send VIRTIO_BLK_T_GET_LONG_ID.

Interestingly (at least for Linux) sending VIRTIO_BLK_T_GET_LONG_ID
when the hypervisor doesn't support it returns -EOPNOTSUPP, but I can
add a feature bit as well.

> >  \end{lstlisting}
> >  
> >  The \field{flags} bitfield is ignored by the device unless
> > @@ -515,9 +516,26 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
> >  the device to discard the specified range, provided that following reads return
> >  zeroes.
> >  
> > -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.
> > +VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID requests fetch the
> > +device ID string from the device into \field{data}.  The device ID
> > +string is an ASCII string which can be up to 247 bytes long.
> > +
> > +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.)
> > +
> > +VIRTIO_BLK_T_GET_LONG_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 MUST be NUL terminated.
> 
> That's a lot of padding) Sure u do not want to use the actual length?

I'm not too clear on this (and the spec is also unclear), but it seems
the buffer is allocated in the guest RAM?  In that case since it
doesn't know the length in advance it must allocate a fixed size buffer.

[...]
> > +(non-truncated) device ID.  In this case a guest which has not opted
> 
> avoid "guest"

Is "driver" preferred?

I'll send a follow up addressing your other points, but probably not today.

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