Re: [Qemu-devel] [PATCH 0/3] -readconfig: accept fd=<fd> option (v2)

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/19/2012 11:39 AM, Eduardo Habkost wrote:
> On Mon, Mar 19, 2012 at 11:21:07AM -0500, Anthony Liguori wrote:
>> On 03/19/2012 11:06 AM, Eduardo Habkost wrote:
>>> On Mon, Mar 19, 2012 at 10:39:10AM -0500, Anthony Liguori wrote:
>>>> On 03/19/2012 10:37 AM, Eduardo Habkost wrote:
>>>>> On Mon, Mar 19, 2012 at 10:10:27AM -0500, Anthony Liguori wrote:
>>>>>> On 03/19/2012 09:54 AM, Eduardo Habkost wrote:
>>>>>>> This is a resubmit of a previous series I sent as a RFC, with some changes to
>>>>>>> prepare for an upcoming patch that will make additional changes to the default
>>>>>>> config-file loading code.
>>>>>>>
>>>>>>> This series needs be applied on top of the "./configure --confdir" series I
>>>>>>> sent today.
>>>>>>
>>>>>> Why not just use /dev/fd/N  ?
>>>>>
>>>>> Personally, I don't like filenames with special meanings (as not every
>>>>> OS has /dev/fd we would have to treat them specially), or filenames that
>>>>> become non-extensible mini-languages by themselves. Many other
>>>>> command-line options use the key=value syntax, and some already have an
>>>>> "fd" option, so this just follows the convention.
>>>>
>>>> But you're also breaking compat, which is not something to be done lightly.
>>>
>>> True. In that case, I propose adding a "-config" option that is more
>>> extensible than the current one, instead of defining a new mini-language
>>> for -readconfig that looks like a file path but has hidden complexities
>>> behind it.
>>
>> What?  /dev/fd is a pretty standard unix feature.  It'll work today
>> with existing versions of QEMU.
>
> When I replied, I was thinking of this proposal:
> http://marc.info/?l=qemu-devel&m=133076148831720
> If you are proposing having zero special-case code to Qemu because of
> /dev/fd, it's OK to me.
>
>>>>> Also, this is more extensible to allow more options to be added to
>>>>> -readconfig if needed (for example: debugging options, or the
>>>>> help=defconfig option I added on the RFC series I sent after this one).
>>>>
>>>> I'd personally prefer to keep readconfig simple.  See the series I
>>>> sent out as an RFC.
>>>
>>> If you are supporting FDs, the complexity is already there. Using the
>>> key=value format just makes the complexity explicit (and familiar, for
>>> humans and code that already uses key=value for other options) instead
>>> of hiding it behind magic filenames.
>>>
>>> I still have to take a look at your series.
>>
>> I think there are cases where /dev/fd doesn't make any sense as an
>> interface (like tun/tap) because tun/tap doesn't have normal file
>> semantics.
>>
>> Likewise, block devices don't act like normal files so you need to
>> treat fd differently than you treat a file path.
>>
>> But for something like the BIOS file, config files, kernels, etc,
>> they are all just simple files and instead of making everything take
>> a fd:, we can (and should) just use the existing unix mechanism for
>> this.
>
> OK to me, if that doesn't require code to handle "/dev/fd/" as special
> inside Qemu, but just use what the OS provides. I am just against making
> magic filenames special.
>
> I was still considering adding a key=value interface for -readconfig (or
> an equivalent -config parameter) because of the debugging and probing
> options I would like to add, but those options could be enabled/disabled
> somewhere else, so there wouldn't be a strong reason for it anymore.
>
> On the other hand, I:
>
> - Would like to let the user (a human) list where are the default config
>    files being used by Qemu;

This should be provided via a QMP command and as part of -query-capabilities 
(see previous series).

Regards,

Anthony Liguori