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
