Re: [PATCH v2 2/4] smbus: Fix spd_data_generate() error API violation

[Markus Armbruster]

BALATON Zoltan <balaton@eik.bme.hu> writes:

> On Sat, 27 Jun 2020, Markus Armbruster wrote:
>> Quick reply without having thought through the issues at all: I'm not
>
> Does that mean you'll reply later with more detail or this is all you
> had to say about this? (Just to know if I should wait for another
> reply.)

Not sure I can find the time before the soft freeze.  Best not to wait
for me.

>> opposed to you doing work to enable additional or even arbitrary memory
>> sizes where these actually work.  I'm first and foremost opposed to me
>> wasting time on "improving" code that is not used for anything.  That's
>> why I dumbed down spd_data_generate().
>
> It was used by sam460ex until moving ram allocation to memdev broke it.
>
>> Secondly, I'm opposed to QEMU "correcting" user configuration.  I want
>> QEMU do exactly what it's told, and fail with a clear error message when
>> that is not possible.  The error message may include hints for the user
>> on how to correct the configuration.
>
> I don't agree with that. It's already hard enough for non-expert users
> to figure out the needed command line switches, making that even
> harder by throwing back an error for everything that could work just
> not exactly specified is needlessly annoying them further. To the
> point of chasing them away from using QEMU. A lot of people prefer
> VMWare or VirtualBox for this reason and only try QEMU if there's no
> other way.

We don't have to agree on everything.  I'm not the QEMU CLI dictator.
The status quo is pretty clear, though:

    $ qemu-system-ppc64 -help
    [...]
    -m [size=]megs[,slots=n,maxmem=size]
                    configure guest RAM
                    size: initial amount of guest memory
    [...]

It says "Initial amount of guest memory", not "Approximate amount of
guest memory" or something like that.

If we decide we want to change it from "Initial amount of guest memory"
to some "do what I mean" behavior, then that behavior needs to be
documented.

Moreover, if DWIM is appropriate for one machine, it's probably
appropriate for all of them.  The CLI should be as consistent as we can
make it across machines.