QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Aleksandar Markovic <aleksandar.m.mail@gmail.com>
Cc: Rajath Shashidhara <rajaths@cs.utexas.edu>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: Looking for issues/features for my first contribution
Date: Sun, 10 Nov 2019 14:33:39 +0000
Message-ID: <CAFEAcA_OGddfM-4kbd+RHz4DA_69E3q-vdYv1Cr5AUDmSYUyiA@mail.gmail.com> (raw)
In-Reply-To: <CAL1e-=jONDYiF+W6cEvrDFN_RkGSS3FVmaaj2-YE0RpO=GOb7w@mail.gmail.com>

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.

-- PMM

  reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 23:50 Rajath Shashidhara
2019-11-07 10:37 ` Aleksandar Markovic
2019-11-07 13:33   ` Aleksandar Markovic
2019-11-07 18:49     ` Rajath Shashidhara
2019-11-08  2:39     ` Rajath Shashidhara
2019-11-08  9:08       ` Alex Bennée
2019-11-08 13:05         ` Richard Henderson
2019-11-08 19:31       ` Aleksandar Markovic
2019-11-09 16:01         ` Peter Maydell
2019-11-09 21:08           ` Aleksandar Markovic
2019-11-10 14:33             ` Peter Maydell [this message]
2019-11-08 19:36       ` Aleksandar Markovic
2019-11-08 21:54         ` BALATON Zoltan
2019-11-09 19:46       ` Aleksandar Markovic
2019-11-09 21:33         ` Rajath Shashidhara
2019-11-09 23:55           ` Aleksandar Markovic
2019-11-07 11:18 ` Alex Bennée
2019-11-07 13:54 ` Stefan Hajnoczi
2019-11-07 18:51   ` Rajath Shashidhara

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFEAcA_OGddfM-4kbd+RHz4DA_69E3q-vdYv1Cr5AUDmSYUyiA@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=aleksandar.m.mail@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rajaths@cs.utexas.edu \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git