From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Luis R. Rodriguez" <mcgrof@gmail.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH 2/2] mkfs: remove notion of config "type"
Date: Sat, 16 Jun 2018 10:17:43 +1000 [thread overview]
Message-ID: <20180616001743.GT10363@dastard> (raw)
In-Reply-To: <235ac120-5a94-0207-da54-badaa307502e@sandeen.net>
On Thu, Jun 14, 2018 at 09:45:49PM -0500, Eric Sandeen wrote:
>
>
> On 6/14/18 9:33 PM, Dave Chinner wrote:
> > On Thu, Jun 14, 2018 at 07:10:09PM -0700, Luis R. Rodriguez wrote:
> >> Silly mobile gmail interface not letting me bottom-post... What if we treat
> >> no version being present as version 0?
> >
> > We haven't released anything yet so we should put it in there from
> > the start rather than having to work around the lack of a version
> > field later.
>
> So, pretend I'm dumb ('cause I often am) and spell it out for me, what would
> we do with a version?
>
> If a config file contains a section or token that some version of mkfs doesn't
> understand, it'll fail.
>
> If we try to read a config file with a too-new version, we'd ... fail?
Fail with a useful error message, rather than do something
unexpected or incorrect.
Let's face it - the config file is a persistent, on-disk structure
that we have to handle in both forwards and backwards compatible
manners for many, many years. It's no different to the on-disk
format in that respect. Why wouldn't we apply the same guards for
format changes we apply to syscalls, ioctls, on-disk formats, etc
that all have the same long term compatibility requirements?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-06-16 0:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-13 19:33 [PATCH 0/2] mkfs: 2 more fixes Eric Sandeen
2018-06-13 19:34 ` [PATCH 1/2] mkfs: initialize return value of parse_config_stream to success Eric Sandeen
2018-06-14 8:48 ` Carlos Maiolino
2018-06-14 16:20 ` Luis R. Rodriguez
2018-06-14 16:41 ` Darrick J. Wong
2018-06-13 19:37 ` [PATCH 2/2] mkfs: remove notion of config "type" Eric Sandeen
2018-06-14 9:46 ` Carlos Maiolino
2018-06-14 16:19 ` Luis R. Rodriguez
2018-06-14 16:40 ` Eric Sandeen
2018-06-14 16:41 ` Darrick J. Wong
2018-06-14 23:42 ` Dave Chinner
[not found] ` <CAB=NE6V7JmsPpkCB1zp0CuY5YTJvMonG7UJPjScKYVJZLWb3xg@mail.gmail.com>
2018-06-15 2:33 ` Dave Chinner
2018-06-15 2:45 ` Eric Sandeen
2018-06-16 0:17 ` Dave Chinner [this message]
2018-06-16 0:55 ` Eric Sandeen
2018-06-16 2:44 ` Dave Chinner
2018-06-16 4:35 ` cfg file versioning (was: [PATCH 2/2] mkfs: remove notion of config "type") Eric Sandeen
2018-06-14 15:43 ` [PATCH 3/2] mkfs: manpage fixups in config file section Eric Sandeen
2018-06-14 16:43 ` Darrick J. Wong
2018-06-14 16:20 ` [PATCH 4/2] mkfs: add -c option to the --help screen Darrick J. Wong
2018-06-14 16:34 ` Eric Sandeen
2018-06-14 16:49 ` Luis R. Rodriguez
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=20180616001743.GT10363@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.