qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH 1/6] utils/python_api: add scripting interfa


From: Balamuruhan S
Subject: Re: [Qemu-devel] [RFC PATCH 1/6] utils/python_api: add scripting interface for Qemu with python lib
Date: Mon, 12 Aug 2019 10:23:20 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1


On 8/9/19 2:16 PM, Stefan Hajnoczi wrote:
> On Thu, Aug 08, 2019 at 11:53:07AM +0100, Daniel P. Berrangé wrote:
>> On Thu, Aug 08, 2019 at 11:10:13AM +0100, Stefan Hajnoczi wrote:
>>> On Wed, Aug 07, 2019 at 12:20:47PM +0200, Philippe Mathieu-Daudé wrote:
>>>>> +void python_args_clean(char *args[], int nargs)
>>>>> +{
>>>>> +    for (int i = 0; i < nargs; i++) {
>>>>> +        g_free(args[i]);
>>>>> +    }
>>>>> +}
>>>>>
>>>> Wondering about security, is this feature safe to enable in production
>>>> environment? It seems to bypass all the hard effort to harden QEMU 
>>>> security.
>>> This seems like a feature that distros would not enable.  Only users
>>> building QEMU from source could enable it.
>> Well that's true when this scripting is only used from one obscure ppc
>> device. Once merged though, its inevitable that people will want to
>> extend scripting to more & more parts of QEMU code. This is a big can
>> of worms...
> When it gets used in new contexts it will be necessary to address
> problems or accept that it is unsuitable for those use cases.  Starting
> simple and dealing with challenges as and when necessary seems okay to
> me.
>
> I think we should give features a chance in QEMU if there is a
> maintainer to support them.  I don't want to use this feature myself and
> I see lots of issues with it for my use cases, but if it is compiled out
> and doesn't place many requirements on code that does not use it, let's
> give it a chance.
>
> My main concern is licensing.  I think the QEMU Python API should be GPL
> licensed because these scripts are executing as part of the QEMU
> process.
>
> Beyond that, let's see if people find this feature useful.  Maybe it
> will die and be removed, maybe it will become popular and we'll have to
> change our perspective :).

Thank you all for review and sharing the thoughts :) 

>
> Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]