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

[Anthony Liguori]

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