Re: [Xen-devel] [PATCH v2] xen: Allow a default compiled-in command line using Kconfig

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.03.17 at 12:38, <julien.grall@xxxxxxx> wrote:

> 
> On 06/03/17 11:32, Jan Beulich wrote:
>>>>> On 06.03.17 at 12:15, <julien.grall@xxxxxxx> wrote:
>>> On 06/03/17 11:01, Zhongze Liu wrote:
>>>> Added 3 new config entries in common/Kconfig:
>>>>     CMDLINE_BOOL, CMDLINE and CMDLINE_OVERRIDE
>>>>
>>>> These 3 entries enable an embedded command line
>>>> to be compiled in the hypervisor.
>>>>
>>>> If CMDLINE_BOOL is set to y, both arm and x86 startup routines
>>>> will combine the compiled-in command line and the boot loader command line
>>>> together to form a complete command line before calling cmdline_parse().
>>>> And if CMDLINE_OVERRIDE is set to y, boot loader command line
>>>> will be ignored.
>>>
>>> This behavior seems a little odd to me. Why would you want to append the
>>> two command line? And more importantly if the same option is passed
>>> twice, how will this behave?
>>>
>>> For example the compile command line could contain iommu=off, but the
>>> bootloader is passing iommu=on. What would be the final state of the IOMMU?
>>>
>>> This one is quite simple, but you could have options which set flags. So
>>> if you want to override it, the new option would have to unset it.
>>
>> I don't understand this concern - overriding an earlier option by a
>> later one is (supposed to be) well defined, and we even suggest this
>> to people when wanting to try out options without having to edit
>> bootloader (or whatever) config files.
> 
> My concern is not about the override itself but about appending two 
> commandlines option without any explanation whether the built-in 
> commandline will be parsed first.

Oh, agreed - as Andrew has also pointed out, the ordering (and hence
override behavior) needs to be clearly spelled out here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel