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

[Markus Armbruster <armbru@redhat.com>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 22 September 2016 at 12:50, Markus Armbruster <armbru@redhat.com> wrote:
>> However, in the case we're discussing, we're not doing that!  There is
>> no RAM device with a trivial backend folded in.  There's only a weird
>> pseudo-device that copies the contents of a file into memory, then sits
>> around doing absolutely nothing.
>
> It doesn't sit around doing entirely nothing, it sits around
> so that when the machine is reset it can do the copying again...

True :)

> In any case, I'm going to drop patches 7 and 8 from target-arm.next
> for the moment so we can come to a consensus about whether this
> should be -device or -object (and possibly respin the patch to
> use -object if we decide that; hopefully it should be simple...)
> I'll keep patches 1..6 in.

Okay, that gives us a bit of time to try to settle the "is this a
device?" question.  How can we best make progress there?

Progress from where?  Starting from a gut feeling that -device is wrong,
I've come to the conclusion that conceptually, this really isn't a
frontend (-device), but a backend of a split device.  Hard to see
because we traditionally don't model memory devices as device objects of
their own.  Except for more interesting ones: persisent memory such as
flash since forever (because we need a backend to persist it), using
block backends created with -drive, and hot-pluggable memory more
recently (because we need a frontend to plug and unplug), using memory
backends created with -object.

For me, the similarity (at the conceptual level) to the persistent
memory case is striking: in both cases, we need a backend to manage
memory contents.  The difference is that for persistent memory, changes
persist, while for the loader, they get reverted at reset.

At the implementation level, though, the two are sadly different: for
persistent memory, the backend manages just contents, and is oblivious
of where it is mapped.  The mapping is done by binding the backend to a
frontend.  The "generic loader" doesn't just manage contents, it also
monkey-patches arbitrary(?) memory.  Feels like a hack to me.  A useful
hack, given the ways we model memory.

The hack part is perhaps kind of, sort of, almost device-like.  An
argument for using -device could go as follows: this is a device to
monkey patch memory.  It needs a backend to manage the bits, just like
other memory-related devices do.  Since its backend is trivial, we
folded it in rather than make it a separate backend.

If we decide to use this argument for the present interface design, I
want it recorded in the code and commit messages.

If, on the other hand, you come around to prefer a -object interface, it
would be fair to tell me "you want -object, you code it up".

Hmm, we already have a backend managing bits from a file:
memory-backend-file.  Naive question: could a read-only
memory-backend-file serve as backend for the "loader" hack device?
Mind, I'm not suggesting this is what we should do, I'm only trying to
understand how the new folded-in backend is related to existing
backends.