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