From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:60911 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750925AbeECAAS (ORCPT ); Wed, 2 May 2018 20:00:18 -0400 Date: Thu, 3 May 2018 00:00:15 +0000 From: "Luis R. Rodriguez" Subject: Re: [PATCH] mkfs.xfs: add configuration file parsing support using our own parser Message-ID: <20180503000015.GF27875@wotan.suse.de> References: <20180313205911.26082-1-mcgrof@kernel.org> <20180313213916.GD18129@dastard> <20180313235227.GH4449@wotan.suse.de> <20180314035531.GF18129@dastard> <20180314171901.GI4449@wotan.suse.de> <20180314210145.GH18129@dastard> <20180426173739.GA27875@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180426173739.GA27875@wotan.suse.de> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Dave Chinner Cc: sandeen@sandeen.net, darrick.wong@oracle.com, linux-xfs@vger.kernel.org, jack@suse.com, jeffm@suse.com, okurz@suse.com, lpechacek@suse.com, jtulak@redhat.com, tytso@mit.edu, mcgrof@kernel.org On Thu, Apr 26, 2018 at 05:37:39PM +0000, Luis R. Rodriguez wrote: > On Thu, Mar 15, 2018 at 08:01:45AM +1100, Dave Chinner wrote: > > On Wed, Mar 14, 2018 at 05:19:01PM +0000, Luis R. Rodriguez wrote: > > > On Wed, Mar 14, 2018 at 02:55:31PM +1100, Dave Chinner wrote: > > > > On Tue, Mar 13, 2018 at 11:52:27PM +0000, Luis R. Rodriguez wrote: > > > > > On Wed, Mar 14, 2018 at 08:39:16AM +1100, Dave Chinner wrote: > > > > > > > > Basically: > > > > > > > > 1. the default file parsing code needs to go into it's own file. > > > > xfs_mkfs.c is too large and needs to be split into smaller files, so > > > > lets not make it worse by shovelling another 500 lines of code into > > > > it... > > > > > > Sure. > > Other than using its own file you had suggested to have the config stuff have > its own structure. At LSFMM you had also suggested it should have its own > defaults which may change later, however for now they can be the same as the > CLI defaults. I suspect likewise applies for maxval, minval. > > What about the conflict mapping / checkers? Don't we want to share that? If so > it would make sense to share the enums used to describe the individual subopts > as well. If so I'll shove the enums into its own file. The conflict stuff > is already in its own structure, so if we want to *share* that, I could just > move all that into its own set of files and share that. Re-poke. Luis