Re: [Qemu-devel] [PATCH 2/3] scsi-disk: Add device_id property

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

> Am 28.01.2019 um 17:55 hat Markus Armbruster geschrieben:
>> Kevin Wolf <address@hidden> 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.

We could also wean them off the legacy device models.

>> >> 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?

If questions remain, I trust Peter will ask.