From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9fhx-0005y3-9E for qemu-devel@nongnu.org; Mon, 19 Mar 2012 12:45:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9fhh-0004Tq-I7 for qemu-devel@nongnu.org; Mon, 19 Mar 2012 12:45:20 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:39993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9fhh-0004Rp-8r for qemu-devel@nongnu.org; Mon, 19 Mar 2012 12:45:05 -0400 Received: by pbcuo5 with SMTP id uo5so1474687pbc.4 for ; Mon, 19 Mar 2012 09:45:03 -0700 (PDT) Message-ID: <4F67628C.8090509@codemonkey.ws> Date: Mon, 19 Mar 2012 11:45:00 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1332168883-9961-1-git-send-email-ehabkost@redhat.com> <4F674C63.6080009@codemonkey.ws> <20120319153731.GE9375@otherpad.lan.raisama.net> <4F67531E.70206@codemonkey.ws> <20120319160640.GG9375@otherpad.lan.raisama.net> <4F675CF3.4000807@codemonkey.ws> <20120319163910.GK9375@otherpad.lan.raisama.net> In-Reply-To: <20120319163910.GK9375@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/3] -readconfig: accept fd= option (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org 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