Re: Looking for issues/features for my first contribution

[Peter Maydell <peter.maydell@linaro.org>]

On Sat, 9 Nov 2019 at 21:08, Aleksandar Markovic
<aleksandar.m.mail@gmail.com> wrote:
> Given modularity of RasPi, wouldn't it be nice for end users to be able to specify an RTC via command line?

The rtc option specifies properties of the backend of
an rtc device. It doesn't specify what the RTC device
exposed to the guest is. For doing that we use '-device',
but that only works for pluggable devices. In general,
we don't try to model any of that complexity for our
boards, except for the special case where there's a
nice clean interface for what the pluggable device is
(ISA, PCI, USB, etc). You could in theory come up with
a bus class which modelled RasPI pluggable modules and
then implement an RTC that way, but that's a huge amount
of work for a board model which currently is struggling
to get enough developer attention to be usable at all.

> If usage of command line is ruled out, what would be an alternative
> way to integrate particular RTC support in RasPi (for
> any QEMU-supported RTC, not only (for now, just envisioned) DS3231)?

We should just model the devices that the hardware has, so
that when you create a raspi QEMU model you get the same
things that you get if you take a stock raspi board and
power it up. The raspi board model is currently missing
lots and lots of devices, some of which are now
necessary to just be able to boot Linux. So we should
start by getting and keeping it working in a basic form,
before we even think about more obscure optional stuff
like pluggable modules.

One thing we should definitely not do is provide
a model of "some random RTC we happen to have a device
model of", just because we have a model handy. My
experience is that it's really important to stick to
a line of "just model what the real hardware does",
and not put in "QEMU does this other thing" behaviour:
it may seem convenient in the short term but it turns
into a real pain to maintain in the long term. The
actual hardware specs provide a nice clean "this is
what correct behaviour of a model should be" definition.

thanks
-- PMM