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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

>
>
>>> 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.

Regards,

Anthony Liguori