qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader


From: Alistair Francis
Subject: Re: [Qemu-devel] [PATCH v11 0/8] Add a generic loader
Date: Wed, 28 Sep 2016 15:48:50 -0700

On Tue, Sep 27, 2016 at 7:04 PM, Markus Armbruster <address@hidden> wrote:
> Alistair Francis <address@hidden> writes:
>
>> On Tue, Sep 27, 2016 at 8:40 AM, Markus Armbruster <address@hidden> wrote:
>>> Paolo Bonzini <address@hidden> writes:
>>>
>>>> It does whatever cpu_physical_memory_write_rom (and hence
>>>> cpu_memory_rw_debug, which has more callers) do.
>>>>
>>>>> What happens when you try to monkey-patch and address that isn't
>>>>> connected to anything?
>>>>
>>>> /dev/null
>>>>
>>>>> What happens when you try to monkey-patch some device's ROM?
>>>>
>>>> Overwritten.
>>>>
>>>>> Memory-mapped I/O?
>>>>
>>>> Ignored.
>>>>
>>>>> What happens when you monkey-patch persistent memory, such as pflash
>>>>> backed by a block backend?
>>>>
>>>> Overwritten (but not flushed).
>>>>
>>>>> What happens if the address range crosses device boundaries?
>>>>
>>>> Writes over each area separately.
>>>
>>> Rejecting the ones that don't actually load stuff would be nice, but not
>>> a condition for merging this.
>>>
>>>>> >> If we decide to use this argument for the present interface design, I
>>>>> >> want it recorded in the code and commit messages.
>>>>>
>>>>> Fair request, don't you think?
>>>>
>>>> Yes, of course.
>>>
>>> Okay, looking forward to these improvements.
>>
>> Ok, so does this mean with the correct justification that Markus
>> mentions above this is fine to keep using -device?
>
> Yes, I've convinced myself that -device is no worse than -object.  All
> I'm asking for is to record the argument for -device properly.
>
> It took me a while to arrive at this conclusion.  If you'd like to
> retrace my steps, look for "An argument for using -device could go as
> follows" in Message-ID: <address@hidden>.
>
>> The justification is along the lines of the backend required is so
>> trivial that we just merged it in with the frontend.
>
> Two points: one, why is this a device, and two, why isn't it a split
> device.  Point one is more important.  The argument I could by there:
> it's a thoroughly weird device that provides no hardware interface of
> its own, but instead monkey patches memory provided by something else
> (devices or the board).

Sounds fair. I'm resending my last two patches now with an updated
commit message.

Thanks,

Alistair

>



reply via email to

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