Am 28.01.2019 um 17:55 hat Markus Armbruster geschrieben:
Kevin Wolf <kwolf(a)redhat.com> writes:
> Am 28.01.2019 um 09:50 hat Peter Krempa geschrieben:
[...]
>> 2) Is actually using 'scsi-cd'/'scsi-hd' the better option than
>> 'scsi-disk'?
>
> Yes, scsi-disk is a legacy device. Maybe we should formally deprecate
> it.
There's an internal use in scsi_bus_legacy_add_drive(), which in turn
powers two legacy features:
1. -drive if=scsi
Creates scsi-disk frontends.
Only works with onboard HBAs since commit 14545097267, v2.12.0.
2. -device usb-storage
Bad magic: usb-storage pretends to be a block device, but it's really
a SCSI bus that can serve only a single device, which it creates
automatically.
If we deprecate scsi-disk, we should deprecate these, too. Can't say
whether that's practical right now.
Most likely not worth the effort anyway. I don't think it's blocking
anything.
>> 3) Since upstream libvirt supports qemu-1.5 and newer and
'scsi-cd' is
>> already supported there, can we assume that all newer versions support
>> it? (Basically the question is whether it can be compiled out by
>> upstream means).
>
> I think so.
Compiling out scsi-hd or scsi-cd, but not scsi-disk would be silly. All
three devices are in scsi-disk.c. You'd have to hack that up to be
silly.
I understood this as a question about libvirt, i.e. whether libvirt can
drop/compile out their scsi-disk code and instead assume that scsi-hd/cd
are always present. Maybe I misunderstood, though?
Kevin