Description
This is an issue following the thread on issue #94.
Right now different AIORIs have different methods of exposing backend-specific options. There have been a couple of generalized ways in which users specify these:
ior -a HDF5 -- --collectiveMetadataior -a HDF5 --hdf5.collective_mdior -a HDF5 --custom "hdf5_collective_md=1"ior -a HDF5 --hdf5-collective-md=1
There is the added problem that the current option parser treats anything input via -f as a second-class citizen, which can cause bugs to manifest if the API is specified in the script rather than on the command line.
In such cases, the default API (MPI-IO) would be what gets detected by the time backend->get_options gets called. If the API is then changed to, say, RADOS in the config script, backend->get_options will never get called.
Fixing this issue and bringing command-line options and configfile options at parity might require some major restructuring because the semantics of the command line are different from the config file.
- The command line options can be specified in any order (with the exception of
-f) - The configfile options must be placed in the correct order with respect to the
RUNstatements that are to use those configurations
The correct way to handle specification of the backend-specific options would be to immediately do the following (from ParseCommandLine) every time the API option is specified:
initialTestParams.backend = backend;
initialTestParams.apiVersion = backend->get_version();
if (backend->get_options != NULL) {
option_parse(argc - parsed_options,
argv + parsed_options,
backend->get_options(),
&printhelp);
}
However doing this means that the backend-specific options would have to first be pulled from the remaining CLI and/or configfile options and passed to the backend-specific option_parse before resuming the parsing the "universal" command-line or configfile options as before.
Unless we want to go down this very complex route (essentially build an entire ordered execution plan in memory before doing anything), we'll have to embed backend-specific options in the API option itself. For example,
api=hdf5=collective_md=1,...
This bundles the backend-specific options with the line that should trigger the parsing of these backend-specific options.
Does this seem ridiculous, or should we plan on writing a much more complicated option parser?