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

[Eduardo Habkost]

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.


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

-- 
Eduardo