From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
linux-xfs@vger.kernel.org, darrick.wong@oracle.com,
david@fromorbit.com
Subject: Re: [PATCH v2] mkfs: add mkfs config version specifier for the config file
Date: Tue, 19 Jun 2018 22:57:10 +0200 [thread overview]
Message-ID: <20180619205710.GH7508@wotan.suse.de> (raw)
In-Reply-To: <e09a067d-5412-e0c7-f854-a0c5af1c6828@sandeen.net>
On Tue, Jun 19, 2018 at 02:53:28PM -0500, Eric Sandeen wrote:
> Soo....
>
> I'm really on the fence about versioning at all, because we have yet to
> identify any concrete scenario in which we'd need to bump the version;
> we haven't even defined what exactly the "version" implies.
Right.
> So unless anyone has a concrete example of how a version would be needed,
> functional, reliably-parsed, and well-defined I'm inclined to leave this out.
Dave asked for it, so I would imagine he could make a better case for it.
But from a generic file format point of view, a version typically does
make sense for a slew of reasons, but it is typically the not known, the
unexpected, for which it can be a life saver.
Things that I can mention other than what you mentioned (whether or not
they are good, this is just a list of crazy things):
1) We move from using our own parser to e2fsprogs profile parser (recall
that my studies revealed it was the smallest) or lib_iniconfig (more
robust, and widely used, however a kitchen sink compared to e2fsprogs
profile parser)
Both however support the INI format we are using.
The version however may help to make the old parser not barf if
say we added some magic in the future which would make the old
parser barf.
2) Data type change for an existing token. Say crc=2 was invented
(again just an example), it would barf on the old parser, but with
the version check it would immediately tell you a more meaningful
message.
Perhaps the biggest advantage I can think of then then is a better error
message for a set of supported features, starting with what we have today
reflected as parsed as version 1. This does differ from what we do with
the CLI, however as with the respecification simplifcation done on
config.c in contrast to the CLI respecification checks, I would see
this as a win for users, and yet keeps things simple.
If this seems acceptable and reasonable, then version would be a reflection
of supporting the format and layout of the file, as well was indicative
of supporting only a specific feature set.
Thoughts?
Luis
next prev parent reply other threads:[~2018-06-19 20:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-18 18:05 [PATCH v2] mkfs: add mkfs config version specifier for the config file Luis R. Rodriguez
2018-06-19 19:53 ` Eric Sandeen
2018-06-19 20:57 ` Luis R. Rodriguez [this message]
2018-06-19 21:21 ` Eric Sandeen
2018-06-19 23:52 ` Luis R. Rodriguez
2018-06-20 13:11 ` Jan Tulak
2018-06-20 23:18 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180619205710.GH7508@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox