All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org,
	darrick.wong@oracle.com, jack@suse.com, jeffm@suse.com,
	okurz@suse.com, lpechacek@suse.com, jtulak@redhat.com
Subject: Re: [PATCH v2 2/5] mkfs: move shared structs and cli params into their own headers
Date: Fri, 18 May 2018 10:49:58 +1000	[thread overview]
Message-ID: <20180518004958.GG23861@dastard> (raw)
In-Reply-To: <20180517235403.GB24680@garbanzo.do-not-panic.com>

On Thu, May 17, 2018 at 04:54:03PM -0700, Luis R. Rodriguez wrote:
> On Fri, May 18, 2018 at 08:40:08AM +1000, Dave Chinner wrote:
> > On Thu, May 17, 2018 at 12:26:57PM -0700, Luis R. Rodriguez wrote:
> > > Both struct sb_feat_args and struct mkfs_default_params will be shared
> > > between CLI processing and the configuration file processing added later,
> > > so move these to their own header. The struct cli_params are CLI specific
> > > so move them to its own CLI header as well.
> > 
> > I'd separate out the CLI details when the CLI parsing is split into
> > it's own file - it's not necssary to do that here.
> 
> Alright.
> 
> > > This will help ensure we split things neatly later and also will help
> > > ensure the configuration file processing code from the CLI code are kept
> > > separate and cannot touch each other's data structures. This also makes
> > > it clear what is actually shared between both.
> > > 
> > > There are no introduced functional changes in this commit and no
> > > documentation changes, this is just code shuffling.
> > > 
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > > ---
> > >  mkfs/xfs_mkfs.c        | 115 +------------------------------------------------
> > >  mkfs/xfs_mkfs_cli.h    |  65 ++++++++++++++++++++++++++++
> > >  mkfs/xfs_mkfs_common.h |  64 +++++++++++++++++++++++++++
> > 
> > File names.
> > 
> > xfs_mkfs.c is named that way by an old convention - it's the same as
> > xfs_repair.c, xfs_db.c, etc. Every other file in the directory does
> > not need a "xfs_mkfs_" prefix.
> 
> Yay.
> 
> > I'd also prefer we don't have "common" as a dumping ground header.
> 
> input.h it is.
> 
> > The CLI, config files, etc are all part of config processing, so
> > config.h would be more appropriate here. Or perhaps "input.h"
> > because they are both processing external inputs....
> 
> Alrighty.
> 
> > >  3 files changed, 131 insertions(+), 113 deletions(-)
> > >  create mode 100644 mkfs/xfs_mkfs_cli.h
> > >  create mode 100644 mkfs/xfs_mkfs_common.h
> > > 
> > > diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
> > > index 95cd6ced13f0..ac97039abc34 100644
> > > --- a/mkfs/xfs_mkfs.c
> > > +++ b/mkfs/xfs_mkfs.c
> > > @@ -20,6 +20,8 @@
> > >  #include <ctype.h>
> > >  #include "xfs_multidisk.h"
> > >  #include "libxcmd.h"
> > > +#include "xfs_mkfs_common.h"
> > > +#include "xfs_mkfs_cli.h"
> > 
> > #include "config.h"
> 
> You mean input.h ? The config.h would be for the configuration file, no?

I suggested both config.h and input.h as potential candidates. Given
that you use config.h in a later patch, i'd suggest that config.h is
the right name for this.

> Both data structures on input.h (sb features and the defaults) were
> introduced in 2017 so using that. Is the following header OK?
> 
> /*                                                                              
>  * Copyright (c) 2017 Red Hat, Inc.                                             
>  * All Rights Reserved.                                                         
>  *                                                                              
>  * This program is free software; you can redistribute it and/or
>  * modify it under the terms of the GNU General Public License as
>  * published by the Free Software Foundation.                                   
>  *                                                                              
>  * This program is distributed in the hope that it would be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  * GNU General Public License for more details.                                 
>  *                                                                              
>  * You should have received a copy of the GNU General Public License
>  * along with this program; if not, write the Free Software Foundation,
>  * Inc.,  51 Franklin St, Fifth Floor, Boston, MA 02110-1301  USA              
>  */    
> 
> Took it as template from a random existing header file.
> 
> I'd prefer if we just went with this as the last paragraph:
> 
>  * You should have received a copy of the GNU General Public License            
>  * along with this program; if not, see <http://www.gnu.org/licenses/>.   
> 
> It used in the kernel as well, and checkpatch now asks you to consider
> this.
> 
> Lemme know your preference.

Use the same as existing files. If we're going to update the
licensing info, then we need to do it for everything, move to spdx
identifiers in the code and use a single copy of each license in the
LICENSE file. That's for another day, though....

> > > @@ -0,0 +1,64 @@
> > > +#ifndef _XFS_MKFS_COMMON_H
> > > +#define _XFS_MKFS_COMMON_H
> > > +
> > > +#include "libxfs.h"
> > > +
> > > +#include <ctype.h>
> > 
> > Same as above for license, copyright and includes, except the
> > copyright will also need to include the SGI copyright line from
> > xfs_mkfs.c...
> 
> Why SGI? I don't see anything from SGI on input.h.

Because the sb_feats structure is derived from much older code
abstractions - it pre-existed all refactoring work I did....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-05-18  0:50 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 19:26 [PATCH v2 0/5] xfsprogs: add mkfs.xfs configuration file parsing support Luis R. Rodriguez
2018-05-17 19:26 ` [PATCH v2 1/5] mkfs: distinguish between struct sb_feat_args and struct cli_params Luis R. Rodriguez
2018-05-17 22:02   ` Dave Chinner
2018-05-17 19:26 ` [PATCH v2 2/5] mkfs: move shared structs and cli params into their own headers Luis R. Rodriguez
2018-05-17 22:40   ` Dave Chinner
2018-05-17 23:54     ` Luis R. Rodriguez
2018-05-18  0:49       ` Dave Chinner [this message]
2018-05-19  1:33         ` Luis R. Rodriguez
2018-05-17 19:26 ` [PATCH v2 3/5] mkfs: replace defaults source with an enum Luis R. Rodriguez
2018-05-17 22:48   ` Dave Chinner
2018-05-17 23:09     ` Luis R. Rodriguez
2018-05-18  0:53       ` Dave Chinner
2018-05-17 19:26 ` [PATCH v2 4/5] mkfs: add helpers to process defaults Luis R. Rodriguez
2018-05-17 22:53   ` Dave Chinner
2018-05-18  0:06     ` Luis R. Rodriguez
2018-05-17 19:27 ` [PATCH v2 5/5] mkfs.xfs: add configuration file parsing support using our own parser Luis R. Rodriguez
2018-05-17 21:31   ` Darrick J. Wong
2018-05-18  0:29     ` Luis R. Rodriguez
2018-05-21 18:32     ` Luis R. Rodriguez
2018-05-18  0:44   ` Dave Chinner
2018-05-19  1:32     ` Luis R. Rodriguez
2018-05-21  0:14       ` Dave Chinner
2018-05-21 15:30         ` Darrick J. Wong
2018-05-21 16:58         ` Luis R. Rodriguez
2018-05-22 19:37     ` Luis R. Rodriguez
2018-05-18  3:24   ` Eric Sandeen
2018-05-18  3:46     ` Darrick J. Wong
2018-05-18 15:38       ` Luis R. Rodriguez
2018-05-18 17:09         ` Eric Sandeen
2018-05-18 23:56           ` Luis R. Rodriguez
2018-05-21  9:40             ` Jan Tulak
2018-05-25  0:50               ` Luis R. Rodriguez
2018-05-20  0:16       ` Dave Chinner
2018-05-21 15:33         ` Darrick J. Wong
2018-05-21 17:05           ` Luis R. Rodriguez
2018-05-21 22:10             ` Dave Chinner
2018-05-21 22:24               ` Eric Sandeen
2018-05-22  0:38                 ` Dave Chinner
2018-05-25  0:51                   ` Luis R. Rodriguez
2018-05-25  0:54           ` 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=20180518004958.GG23861@dastard \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.com \
    --cc=jack@suse.com \
    --cc=jeffm@suse.com \
    --cc=jtulak@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lpechacek@suse.com \
    --cc=mcgrof@kernel.org \
    --cc=okurz@suse.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.