From: Peter Maydell <peter.maydell@linaro.org>
To: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Cc: Alistair Francis <alistair23@gmail.com>,
qemu-devel@nongnu.org, qemu-riscv@nongnu.org,
alistair.francis@wdc.com, bmeng@tinylab.org,
liweiwei@iscas.ac.cn, zhiwei_liu@linux.alibaba.com,
palmer@rivosinc.com
Subject: Re: [PATCH v6 04/12] target/riscv/cpu.c: del DEFINE_PROP_END_OF_LIST() from riscv_cpu_extensions
Date: Tue, 15 Aug 2023 14:15:26 +0100 [thread overview]
Message-ID: <CAFEAcA8NKafY0pdHEmJNDavSNw9P=+sO1zGaSbviL1v5oJ2Trw@mail.gmail.com> (raw)
In-Reply-To: <0013e3ed-75ba-1806-45d5-6ca7c00ee917@ventanamicro.com>
On Tue, 15 Aug 2023 at 13:44, Daniel Henrique Barboza
<dbarboza@ventanamicro.com> wrote:
>
>
>
> On 8/10/23 14:49, Alistair Francis wrote:
> > On Thu, Jul 27, 2023 at 6:20 PM Daniel Henrique Barboza
> > <dbarboza@ventanamicro.com> wrote:
> >>
> >> This last blank element is used by the 'for' loop to check if a property
> >> has a valid name.
> >>
> >> Remove it and use ARRAY_SIZE() instead like riscv_cpu_options is already
> >> using. All future arrays will also do the same and we'll able to
> >> encapsulate more repetitions in macros later on.
> >
> > Is this the right approach? This seem different to the rest of QEMU
>
> I am not sure if we have a 'right approach' in this case or not. I see both
> being used in QEMU.
The major use of the DEFINE_PROP_* macros is for creating
a property list to pass to device_class_set_props(). Those
lists must be terminated with the DEFINE_PROP_END_OF_LIST()
marker (because the function takes a pointer and can't tell
the size of the list with ARRAY_SIZE()). For cases like this
where you're writing code locally to manually iterate through
the array and never pass it to any other code in QEMU, both
approaches work. But it does seem to me a little confusing
to have a non-terminated property array.
thanks
-- PMM
next prev parent reply other threads:[~2023-08-15 13:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 22:09 [PATCH v6 00/12] riscv: add 'max' CPU, deprecate 'any' Daniel Henrique Barboza
2023-07-27 22:09 ` [PATCH v6 01/12] target/riscv/cpu.c: split CPU options from riscv_cpu_extensions[] Daniel Henrique Barboza
2023-07-27 22:09 ` [PATCH v6 02/12] target/riscv/cpu.c: skip 'bool' check when filtering KVM props Daniel Henrique Barboza
2023-07-27 22:09 ` [PATCH v6 03/12] target/riscv/cpu.c: split kvm prop handling to its own helper Daniel Henrique Barboza
2023-08-10 17:42 ` Alistair Francis
2023-07-27 22:09 ` [PATCH v6 04/12] target/riscv/cpu.c: del DEFINE_PROP_END_OF_LIST() from riscv_cpu_extensions Daniel Henrique Barboza
2023-08-10 17:49 ` Alistair Francis
2023-08-15 12:43 ` Daniel Henrique Barboza
2023-08-15 13:15 ` Peter Maydell [this message]
2023-08-15 17:25 ` Daniel Henrique Barboza
2023-07-27 22:09 ` [PATCH v6 05/12] target/riscv/cpu.c: split vendor exts from riscv_cpu_extensions[] Daniel Henrique Barboza
2023-07-27 22:09 ` [PATCH v6 06/12] target/riscv/cpu.c: split non-ratified " Daniel Henrique Barboza
2023-07-27 22:09 ` [PATCH v6 07/12] target/riscv/cpu.c: add ADD_CPU_QDEV_PROPERTIES_ARRAY() macro Daniel Henrique Barboza
2023-07-27 22:09 ` [PATCH v6 08/12] target/riscv/cpu.c: add ADD_UNAVAIL_KVM_PROP_ARRAY() macro Daniel Henrique Barboza
2023-07-27 22:09 ` [PATCH v6 09/12] target/riscv/cpu.c: limit cfg->vext_spec log message Daniel Henrique Barboza
2023-07-28 1:02 ` Weiwei Li
2023-08-10 17:54 ` Alistair Francis
2023-07-27 22:09 ` [PATCH v6 10/12] target/riscv: add 'max' CPU type Daniel Henrique Barboza
2023-08-10 17:56 ` Alistair Francis
2023-07-27 22:09 ` [PATCH v6 11/12] avocado, risc-v: add opensbi tests for 'max' CPU Daniel Henrique Barboza
2023-08-10 17:56 ` Alistair Francis
2023-07-27 22:09 ` [PATCH v6 12/12] target/riscv: deprecate the 'any' CPU type Daniel Henrique Barboza
2023-08-10 17:51 ` Alistair Francis
Reply instructions:
You may reply publicly 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFEAcA8NKafY0pdHEmJNDavSNw9P=+sO1zGaSbviL1v5oJ2Trw@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=bmeng@tinylab.org \
--cc=dbarboza@ventanamicro.com \
--cc=liweiwei@iscas.ac.cn \
--cc=palmer@rivosinc.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=zhiwei_liu@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).