From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>, virtio-comment@lists.linux.dev
Subject: Re: [PATCH v3 1/1] device-types/blk/description.tex: Allow longer device IDs to be returned
Date: Tue, 8 Sep 2026 12:43:09 -0400 [thread overview]
Message-ID: <20260908123542-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20260908154640.GW1436@redhat.com>
On Tue, Sep 08, 2026 at 04:46:40PM +0100, Richard W.M. Jones wrote:
> On Tue, Sep 08, 2026 at 11:14:46AM -0400, Stefan Hajnoczi wrote:
> > On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> > > +Although 247 byte device ID strings are allowed, there may be
> > > +interoperability problems if strings longer than 128 bytes are used.
> >
> > Can you be more specific? Is the concern that the guest software stack
> > above of the driver may not be prepared for serial strings longer than
> > 128 bytes?
>
> I'll add more detail in the next version, but in brief the problems
> are twofold:
>
> (1) Windows supports up to 128 "characters" (they're not precise but
> they probably mean Unicode codepoints from the Basic Multilingual Plane):
>
> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number
>
> (2) When udev tries to encode a very long serial into a
> /dev/disk/by-id path you end up uncomfortably close to NAME_MAX (255).
>
> > > +It is also advisable to use only 7 bit ASCII characters.
> >
> > Versus "The device ID string is an ASCII string which can be up to 247
> > bytes long" earlier in this patch. Is ASCII a "SHOULD" or a "MUST"?
>
> It's "SHOULD". I can't see any good coming from trying to use
> anything except letters, numbers and dashes in a serial, but both
> Linux and Windows (see above) could in theory handle Unicode.
>
> Rich.
Linux actually has code to try and handle that. unicode
is actually the less problematic part - ascii is
full of pitfalls, eith things like
slashes are much weirder - e.g. udev will create
a subdirectory with slashes. what will windows do?
and what will it do with backslashes? /me shrugs
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
next prev parent reply other threads:[~2026-09-08 16:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 9:40 [PATCH v3 0/1] [PATCH v3] device-types/blk/description.tex: Allow longer device IDs to be returned Richard W.M. Jones
2026-09-08 9:40 ` [PATCH v3 1/1] " Richard W.M. Jones
2026-09-08 10:57 ` Michael S. Tsirkin
2026-09-08 11:51 ` Richard W.M. Jones
2026-09-08 14:16 ` Michael S. Tsirkin
2026-09-08 15:14 ` Stefan Hajnoczi
2026-09-08 15:46 ` Richard W.M. Jones
2026-09-08 16:43 ` Michael S. Tsirkin [this message]
2026-09-09 2:12 ` Demi Marie Obenour
2026-09-09 3:34 ` Parav Pandit
2026-09-09 7:07 ` Michael S. Tsirkin
2026-09-09 7:05 ` Michael S. Tsirkin
2026-09-08 16:25 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260908123542-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=rjones@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox