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; - Don't want to add Yet Another "-option ?" parameter to Qemu (e.g. "-readconfig ?"). Do you have any suggestions for that? -- Eduardo
