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

Re: [Xen-devel] [PATCH v2 39/52] xen: check parameter validity when parsing command line

>>> On 15.08.17 at 14:54, <jgross@xxxxxxxx> wrote:
> On 14/08/17 14:46, Jan Beulich wrote:
>>>>> On 14.08.17 at 09:08, <jgross@xxxxxxxx> wrote:
>>> --- a/xen/common/kernel.c
>>> +++ b/xen/common/kernel.c
>>>                      optval[-1] = '\0';
>>> +                    break;
>> Why? Applies to further break-s you add: At least in the past we
>> had command line options with two handlers, where each of them
>> needed to be invoked. I don't think we should make such impossible
>> even if right now there aren't any such examples. Yet if you really
>> mean to, then the behavioral change needs to be called out in the
>> description.
> While working on this I realized that this functionality has been
> working only in some cases. The custom parsing functions are being
> called with a copy of the option value, which they modify in some
> cases. So a second handler being called would see another value as
> the first handler, as long as modifying the option value keeps to be
> allowed.
> I see three possibilities here:
> 1. don't allow multiple handlers for the same parameter
> 2. restore the option value before calling each handler (as the
>    error message I'm adding with this patch requires access to the
>    whole option value this wouldn't be too hard)
> 3. don't allow a handler to modify the option value (solves my error
>    message problem, too)
> Any preferences?

I have no particular preference between 2 and 3, but both are
better than 1.


Xen-devel mailing list



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