[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3

On 20/04/18 01:00, Stefano Stabellini wrote:
> On Thu, 19 Apr 2018, Juergen Gross wrote:
>> On 19/04/18 10:06, Andrew Cooper wrote:
>>> On 18/04/2018 23:15, Stefano Stabellini wrote:
>>>>  xen/arch/arm/configs/renesas.config | 80 
>>>> +++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 80 insertions(+)
>>>>  create mode 100644 xen/arch/arm/configs/renesas.config
>>>> diff --git a/xen/arch/arm/configs/renesas.config 
>>>> b/xen/arch/arm/configs/renesas.config
>>>> new file mode 100644
>>>> index 0000000..7ad3f1c
>>>> --- /dev/null
>>>> +++ b/xen/arch/arm/configs/renesas.config
>>>> @@ -0,0 +1,80 @@
>>>> +#
>>>> +# Automatically generated file; DO NOT EDIT.
>>>> +# Xen/arm 4.11-unstable Configuration
>>>> +#
>>> This is now the second Kconfig file we've got added into the tree.  As
>>> with the PV-shim config, keeping it up to date is going to be a little
>>> tricky.
>>> I think we either need a script to keep all of the embedded configs up
>>> to date, or switch to a model (similar to the travis randconfig target)
>>> where it becomes a `make defaultconfig` with certain specific options
>>> forced one way or another (similar to `make {tiny,kvm,xen}config` in
>>> Linux).  The latter means that we only store the specific delta
>>> applicable for purpose, and it will probably change less frequently.
>> I think the easiest way would be to have a config file with only the
>> required non-default options being specified and then run
>> "make olddefconfig" against that (or better: a copy of that in order
>> to avoid modifying a source from git).
>> I'm just writing a patch to do that for the shim config as it is nasty
>> to remove shim.config from my patches in case it has been modified by
>> the build (again) and STGit has picked it up.
> Given that the goal of this kconfig is to provide the smallest possible
> kconfig for a given board, I think that your suggestion wouldn't end up
> improving things much in this case because most options will have to be
> specified as "disabled", otherwise "make olddefconfig" would end up
> enabling some of them by default, which is not what we want.

What's the problem with this?

In case you really do want a config with many non-default settings
you'll have to specify them. So just do it and it's fine.

The alternative would be to specify _all_ entries. I don't see why
this would be better.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.