qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 01/10] ide: Break all non-qdevified controllers


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 01/10] ide: Break all non-qdevified controllers
Date: Mon, 17 Dec 2012 16:38:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Alexander Graf <address@hidden> writes:

> On 17.12.2012, at 16:15, Markus Armbruster wrote:
>
>> Alexander Graf <address@hidden> writes:
>> 
>>> On 17.12.2012, at 15:43, Markus Armbruster wrote:
>>> 
>>>> Alexander Graf <address@hidden> writes:
>>>> 
>>>>> On 17.12.2012, at 15:05, Markus Armbruster wrote:
>>>>> 
>>>>>> They complicate IDE data structures and keep getting in the way.
>>>>>> Also, TRIM support (commit d353fb72) is broken for them, because
>>>>>> ide_identify() accesses IDEDevice member conf, but IDEDevice exists
>>>>>> only with qdevified controllers.
>>>>>> 
>>>>>> The non-qdevified controllers are still there, but attempting to
>>>>>> connect devices to them fails with "IDE controller not qdevified yet;
>>>>>> drive <name> ignored".
>>>>>> 
>>>>>> Affected machines:
>>>>>> 
>>>>>> * g3beige's first IDE channel (MacIO)
>>>>>> -hda, -hdb are on first channel, and no longer work
>>>>>> -hdc, -hdd are on second channel, and still work
>>>>>> * mac99's second and third IDE channel (MacIO)
>>>>>> All four IDE drives no longer work
>>>>> 
>>>>> Nack. This breaks the default targets of qemu-system-ppc and
>>>>> qemu-system-ppc64.
>>>> 
>>>> Please tell us how much more time you want to qdevify IDE for these
>>>> targets.  Thanks!
>>> 
>>> I don't know. If it's dear to you, just convert it
>>> yourself. Apparently you're quite deep into the details here already,
>>> so it's a lot easier for you than for me anyways.
>> 
>> These controllers aren't dear to me, they're in the way.  Have been for
>> years.  I doubt hacking them is easier for me than for you.
>
> Windows XP support has been in my way plenty times too. I still don't
> (heavily) suggest dropping it.

I'm not suggesting to drop these targets.  I'm suggesting they get the
maintainance they need to keep up with evolving infrastructure.



reply via email to

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