Hi Stefano
On 23.05.18 00:00, Stefano Stabellini wrote:
On Tue, 22 May 2018, Julien Grall wrote:
It might be easier to maintain if we provide a per platform config option (e.g
CONFIG_RCAR3) that will select driver for that specific board.
The user is then free to select other components (e.g scheduler...). So you
don't impose memaccess disabled, NULL scheduler...
(Thank you Andrii for the suggestion!)
This is a good idea, it would be great to have CONFIG_RCAR3, but it does
not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
are orthogonal, let me explain.
Let's say that we have a CONFIG_RCAR3 that selects everything needed for
the Rcar3, such as:
NR_CPUS, SCIF
and deselects:
ACPI, GICV3, the other UARTs, ARM_SMMU.
We still need a reference kconfig with other not platform specific
options, for instance:
SCHED_NULL
For two reasons:
1) we need a reference kconfig for certifications, it has to include the
choice of schedulers, debug options, etc, which are not Rcar3 specific
2) as per previous discussions, we need a set of pre-canned kconfigs to
establish what we security support
rcar3.config is meant to address these two points. CONFIG_RCAR3 would
not take away the need for rcar3.config, but it would make rcar3.config
shorter and easier to maintain.
CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
is best if I do the work for QEMU only (both CONFIG_QEMU and
qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
rcar3.config) to EPAM. I cannot test it anyway.
We will check v3 patchset on R-Car H3
-- Artem
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
