| Message ID | 62f67117-150d-e456-d9dd-3a19938cb03a@sandeen.net (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Thu, Dec 07, 2017 at 10:13:15PM -0600, Eric Sandeen wrote: > Until we have more than one possible source of configuration, > there is no need to emit the only possibility and clutter > the output. We can decide how it should all look when we > get more than one source. > > Apply some i18n to the config description, though. > > Signed-off-by: Eric Sandeen <sandeen@redhat.com> Looks ok, I guess, Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> (I wonder why Dave put the printf in there, but I'll let him answer that.) > --- > > mkfs/xfs_mkfs.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c > index e38810f..0f7dd92 100644 > --- a/mkfs/xfs_mkfs.c > +++ b/mkfs/xfs_mkfs.c > @@ -3845,7 +3845,7 @@ main( > > /* build time defaults */ > struct mkfs_default_params dft = { > - .source = "package build definitions", > + .source = _("package build definitions"), > .sectorsize = XFS_MIN_SECTORSIZE, > .blocksize = 1 << XFS_DFL_BLOCKSIZE_LOG, > .sb_feat = { > @@ -3881,10 +3881,12 @@ main( > * defaults. If a file exists in <package location>, read in the new > * default values and overwrite them in the &dft structure. This way the > * new defaults will apply before we parse the CLI, and the CLI will > - * still be able to override them. Emit a message to indicate where the > - * defaults being used came from. > + * still be able to override them. When more than one source is > + * implemented, emit a message to indicate where the defaults being > + * used came from. > + * > + * printf(_("Default configuration sourced from %s\n"), dft.source); > */ > - printf(_("Default configuration sourced from %s\n"), dft.source); > > /* copy new defaults into CLI parsing structure */ > memcpy(&cli.sb_feat, &dft.sb_feat, sizeof(cli.sb_feat)); > -- > 1.8.3.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 07, 2017 at 08:21:53PM -0800, Darrick J. Wong wrote: > On Thu, Dec 07, 2017 at 10:13:15PM -0600, Eric Sandeen wrote: > > Until we have more than one possible source of configuration, > > there is no need to emit the only possibility and clutter > > the output. We can decide how it should all look when we > > get more than one source. > > > > Apply some i18n to the config description, though. > > > > Signed-off-by: Eric Sandeen <sandeen@redhat.com> > > Looks ok, I guess, > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> > > (I wonder why Dave put the printf in there, but I'll let him answer that.) Because I wanted to demonstrate to everyone where the config file based defaults should be introduced. i.e. before the printf that says where the defaults were sourced from! -Dave.
On 12/7/17 10:54 PM, Dave Chinner wrote: > On Thu, Dec 07, 2017 at 08:21:53PM -0800, Darrick J. Wong wrote: >> On Thu, Dec 07, 2017 at 10:13:15PM -0600, Eric Sandeen wrote: >>> Until we have more than one possible source of configuration, >>> there is no need to emit the only possibility and clutter >>> the output. We can decide how it should all look when we >>> get more than one source. >>> >>> Apply some i18n to the config description, though. >>> >>> Signed-off-by: Eric Sandeen <sandeen@redhat.com> >> >> Looks ok, I guess, >> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> >> >> (I wonder why Dave put the printf in there, but I'll let him answer that.) > > Because I wanted to demonstrate to everyone where the config file > based defaults should be introduced. i.e. before the printf that > says where the defaults were sourced from! Sure, and having the infrastructure and the big comment helps, and it's all still there. But we shouldn't emit configuration details about non-configurable things to every user in the meantime, just to remind developers what to do next. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index e38810f..0f7dd92 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -3845,7 +3845,7 @@ main( /* build time defaults */ struct mkfs_default_params dft = { - .source = "package build definitions", + .source = _("package build definitions"), .sectorsize = XFS_MIN_SECTORSIZE, .blocksize = 1 << XFS_DFL_BLOCKSIZE_LOG, .sb_feat = { @@ -3881,10 +3881,12 @@ main( * defaults. If a file exists in <package location>, read in the new * default values and overwrite them in the &dft structure. This way the * new defaults will apply before we parse the CLI, and the CLI will - * still be able to override them. Emit a message to indicate where the - * defaults being used came from. + * still be able to override them. When more than one source is + * implemented, emit a message to indicate where the defaults being + * used came from. + * + * printf(_("Default configuration sourced from %s\n"), dft.source); */ - printf(_("Default configuration sourced from %s\n"), dft.source); /* copy new defaults into CLI parsing structure */ memcpy(&cli.sb_feat, &dft.sb_feat, sizeof(cli.sb_feat));
Until we have more than one possible source of configuration, there is no need to emit the only possibility and clutter the output. We can decide how it should all look when we get more than one source. Apply some i18n to the config description, though. Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- mkfs/xfs_mkfs.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)