Handle long device names when creating QEMU device tags #13516
Conversation
hamistao
force-pushed
the
issue13495/handle_long_device_names
branch
4 times, most recently
from
31795e6
to
1513425
Compare
hamistao
changed the title
|
Please can this be rebased too |
hamistao
force-pushed
the
issue13495/handle_long_device_names
branch
2 times, most recently
from
d0a325e
to
17826c4
Compare
hamistao
force-pushed
the
issue13495/handle_long_device_names
branch
from
17826c4
to
441572b
Compare
|
@tomponline This is ready again. Sorry @ru-fu this was my mistake, I believe your help is not needed for this one. |
There was a problem hiding this comment.
@hamistao please can you confirm that no device name that previously worked has been changed when passed to qemu, and only longer device names that didn't work previously are now hashed?
Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
…tdevs Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
hamistao
force-pushed
the
issue13495/handle_long_device_names
branch
from
441572b
to
342bef9
Compare
|
@tomponline Yes, I can. I ran some tests to confirm and any name up to 27 chars is not being hashed. |
|
@tomponline To be more specific, some tags have a limit of 31 chars and others have a limit of 36. The shorter tags are only used during cold-plugging, so a hot-plugged device could work with the limit of 36 (until VM restart) but not a cold-plugged one. So I chose 31 as the limit to maintain a standard and keep the code simpler. If you think it is best, I could use different limits for each case as to not alter the behavior in the hot-plugging scenario. |
Fixes #13495.
Helps to avoid problems with these tests.
The old
blockNodeNamefunction was modified, renamed and repurposed to also help generating device tags for QEMU.