On Mon, Jan 28, 2019 at 17:55:14 +0100, Markus Armbruster wrote: > Kevin Wolf <kwolf@xxxxxxxxxx> 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. Unfortunately we did not bother replacing usb-storage yet. scsi-disk was unused for some time (if scsi-hd was supported). I just deleted any mentions of it from libvirt now. > > >> 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. That would be a downstream modification of qemu thus libvirt will not want to support that.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
