qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [libvirt] [Qemu-devel] [PATCH 2/3] scsi-disk: Add devic


From: Peter Krempa
Subject: Re: [Qemu-block] [libvirt] [Qemu-devel] [PATCH 2/3] scsi-disk: Add device_id property
Date: Tue, 29 Jan 2019 13:25:49 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

On Tue, Jan 29, 2019 at 08:10:19 +0100, Markus Armbruster wrote:
> 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.

In libvirt we should get rid of usb-storage usage, but I remember there
were a few ABI-related problems so that we could not plainly switch to
uas.

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

I in fact wanted to know whether it's possible to compile it out of qemu
somehow. Removing it from libvirt is then easy.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]