John Snow <js...@redhat.com> writes: > On 10/7/19 5:49 AM, Markus Armbruster wrote: >> John Snow <js...@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 <js...@redhat.com> [...] > I'll respin to hit the tests with a stiffer scrub-brush. Thanks! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
