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

[Zhongze Liu <blackskygg@xxxxxxxxx>]

>2017-03-13 19:52 GMT+08:00 Jan Beulich <JBeulich@xxxxxxxx>:
>>>> @@ -1566,14 +1557,14 @@ void __init noreturn __start_xen(unsigned long 
>>>> mbi_p)
>>>>
>>>>      /* Grab the DOM0 command line. */
>>>>      cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL);
>>>> -    if ( (cmdline != NULL) || (kextra != NULL) )
>>>> +    if ( (cmdline != NULL) || strlen(kextra) )
>>>
>>> Is there any reason why kextra can't come out as NULL if unset,
>>> avoiding the need to touch the code here? That would also avoid
>>> making kextra a static variable.
>>>
>>
>> In the original code, kextra is a pointer to a suffix of the original
>> cmdline. It's
>> orphaned from cmdline by turning the first blank in " -- " into a '\0'.
>> But now since the dom0 options can appear in both CONFIG_CMDLINE and
>> the bootloader
>> cmdline, there must be some place (an array) to hold the concatenated
>> dom0 option string.
>> So if we want to avoid modifying this piece of code, I can only come
>> up with two solutions:
>> 1.  Define a new array in this function and let kextra point to it.
>> Set kextra to NULL if the array is empty.
>>      But I think this is too awkward.
>>  2. Define a new array,  say, opt_dom0_options[],  in kernel.c, and
>> return the pointer to this array back to
>>      the caller when cmdline_parse() is invoked, or return NULL if the
>> array is empty.
>> What do you say?
>
> Having thought about it again, I'm actually no longer of the opinion
> that hard coding a Dom0 command line (portion) in the hypervisor
> is sensible at all. With that eliminated, this discussion aspect is moot
> afaict.
>

That's it! I was just about to ask whether it's worth doing so. After
some thoughts,
I think it makes no sense to allow dom0 options to appear in CONFIG_CMDLINE,
either. What's more, if I don't need to handle it, things become much easier.

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