[Top][All Lists]

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

Re: [Qemu-devel] [RFC PATCH] ssi-sd: Make devices picking up backends un

From: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC PATCH] ssi-sd: Make devices picking up backends unavailable with -device
Date: Wed, 26 Sep 2018 13:46:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Philippe Mathieu-Daudé <address@hidden> writes:

> Hi Markus,
> On 9/26/18 11:00 AM, Markus Armbruster wrote:
>> Device models aren't supposed to go on fishing expeditions for
>> backends.  They should expose suitable properties for the user to set.
>> For onboard devices, board code sets them.
>> Device ssi-sd picks up its block backend in its init() method with
>> drive_get_next() instead.  This mistake is already marked FIXME since
>> commit af9e40a.
>> Unset user_creatable to remove the mistake from our external
>> interface.  Since the SSI bus doesn't support hotplug, only -device
>> can be affected.  Only certain ARM machines provide an SSI bus.
> There is also a MicroBlaze machine.

ssi-sd isn't linked into that one:
qemu-system-microblaze: -device ssi-sd: 'ssi-sd' is not a valid device model 

> Note that out of those target, we could model SSI buses on
> southbridges/LPC devices but there is no interest.
> I'm also spending some hobby time on a MIPS SoC which exposes a SSI bus.
>> Signed-off-by: Markus Armbruster <address@hidden>
>> ---
>> Are there valid uses of -device ssi-sd?  If no, this patch is fine.
>> If yes, this patch breaks them.  But fixing the FIXME will also break
>> them.  What should we do?
> This device was probably orphan (not used) for a long time, and seems
> unusable in it current state to me, see:
> http://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg01757.html

The more that's true, the less we have to worry about preserving
compatibility ;)

> I have to address Peter's comment to my patch noted in my TODO (low
> priority), so I'm OK to get ride of the FIXME.
> I suppose it is easier for you to get your patch in, then let me clean
> that later.

Works for me.

reply via email to

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