[PATCH 0/3] mkfs: Configuration file defined options

[Dave Chinner <david@fromorbit.com>]

Hi Folks,

Because needing config files for mkfs came up yet again in
discussion, here is a simple implementation of INI format config
files. These config files behave identically to options specified on
the command line - the do not change defaults, they do not override
CLI options, they are not overridden by cli options.

Example:

$ echo -e "[metadata]\ncrc = 0" > foo
$ mkfs/mkfs.xfs -N -c file=foo -d file=1,size=100m blah
Ini debug: file foo, section metadata, name crc, value 0
Parameters parsed from config file foo successfully
meta-data=blah                   isize=256    agcount=4, agsize=6400 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0, sparse=0, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=25600, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=853, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
$

And there's a V4 filesystem as specified by the option defined
in the config file. If we do:

$ mkfs/mkfs.xfs -N -c file=foo -m crc=1 -d file=1,size=100m blah
Ini debug: file foo, section metadata, name crc, value 0
-m crc option respecified
Usage: mkfs.xfs
.....
$

You can see it errors out because the CRC option was specified in
both the config file and on the CLI.

There's lots of stuff we can do to make the conflict and respec
error messages better, but that doesn't change the basic
functionality of config file based mkfs options. To allow for future
changes to the way we want to apply the config file, I created a
full option subtype for config files. That means we can add another
option to say "apply config file as default values rather than as
options" if we decide that is functionality that we want to support.

But policy decisions like that are completely separate to the
mechanism, so these patches don't try to address desires to ship
"tuned" configs, system wide option files, shipping distro specific
defaults in config files, etc. This is purely a mechanism to allow
users to specify options via files instead of on the CLI.  No more,
no less.

So to preempt the endless bikeshedding from derailing getting this
functionality merged, all I'm going to say is "no". No feature
creep, no "but I want to ...", "can you make it pink...", nothing.
All I care about is providing a mechanism that people are still
asking for, and that's all I'm going to provide here.

I'm happy to fix bugs and code stuff that people want fixed to get
it merged, but in terms of functionality being provided I'm
essentially saying "take it or leave it" because I'm not going to
waste time bikeshedding this whole thing again.

This has only been given a basic smoke test right now (see above!
:).  I need to get Darrick's tests from the previous round of config
file bikeshedding working in my test environment to do more
substantial testing of this....

Cheers,

Dave.


Dave Chinner (3):
  build: add support for libinih for mkfs
  mkfs: add initial ini format config file parsing support
  mkfs: hook up suboption parsing to ini files

 configure.ac         |   3 +
 include/builddefs.in |   1 +
 include/linux.h      |   2 +-
 m4/package_inih.m4   |  20 ++++
 mkfs/Makefile        |   2 +-
 mkfs/xfs_mkfs.c      | 218 +++++++++++++++++++++++++++++++++++++------
 6 files changed, 218 insertions(+), 28 deletions(-)
 create mode 100644 m4/package_inih.m4

-- 
2.28.0