[libvirt] [PATCH 1/1] IDE: deprecate ide-drive

[Markus Armbruster]

John Snow <jsnow at redhat.com> writes:

> On 10/7/19 5:49 AM, Markus Armbruster wrote:
>> John Snow <jsnow at redhat.com> writes:
>> 
>>> It's an old compatibility shim that just delegates to ide-cd or ide-hd.
>>> I'd like to refactor these some day, and getting rid of the super-object
>>> will make that easier.
>> 
>> Device "scsi-disk" is similar.  However, it's still used by the
>> scsi_bus_legacy_add_drive() magic.  Not sure that's fully deprecated,
>> yet.  If / once it is, we can deprecate "scsi-disk", too.  Anyway, not
>> your department.
>> 
>
> Yeah. I just want to get rid of this to allow myself to do bolder things
> later on.
>
> I have literally no time to do this and it's not really anything that
> would make anyone money, but...
>
> I want to add a few explicit devices:
>
> ata-hd
> ata-cd
> sata-hd
> sata-cd
>
> With some shared state structures that implement common feature subsets,
> like ata_registers, sata_registers, atapi_registers, etc.
>
> I'd also like to separate out frontend and backend state providing a bit
> of a cleaner division between device configuration (parameters on the
> hardware creation itself), emulated device state (ATA register sets and
> state machine), and QEMU backend state (block_backend pointers, aio
> state counters, locks, etc etc etc -- Things solely purposed for
> interacting with the block module.)
>
> I'd also like to make each device type plug into ATA or SATA bus slots
> explicitly -- no more magic IDE devices.
>
> It's like the 5-year itch I can't help but want to scratch. My name's on
> this code and it's UGLY UGLY UGLY!

True!  And that's after Kraxel made it *less* ugly.  Your 5-year itch is
actually a 10-year itch that evolved from an open sore.

> The biggest roadblock to me actually doing this is figuring out how it
> would be even vaguely possible to migrate from ide-hd or ide-cd to the
> newer models -- it might be pretty complex, but maybe I can figure
> something out somehow...

Yes, that's the problem that has blocked further improvement.  Doesn't
mean it's intractable, only that nobody has found the time to tackle it
seriously.

> Well, suggestions welcome.
>
>>> Either way, we don't need this.
>>>
>>> Signed-off-by: John Snow <jsnow at redhat.com>
[...]
> I'll respin to hit the tests with a stiffer scrub-brush.

Thanks!