lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180418181635.GA24031@thinkpad>
Date:   Wed, 18 Apr 2018 20:16:37 +0200
From:   Thymo van Beers <thymovanbeers@...il.com>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] docs: kernel-parameters.txt: Fix whitespace

On Mon, Apr 16, 2018 at 03:03:47PM -0700, Randy Dunlap wrote:
> On 04/16/18 14:49, Thymo van Beers wrote:
> > Some lines used spaces instead of tabs at line start.
> > This can cause mangled lines in editors due to inconsistency.
> > 
> > Replace spaces for tabs where appropriate.
> > 
> > Signed-off-by: Thymo van Beers <thymovanbeers@...il.com>
> > ---
> > Changes in v2:
> >   - Rebase against docs-next
> >   - Fix indentation modifications
> > 
> >  Documentation/admin-guide/kernel-parameters.txt | 136 ++++++++++++------------
> >  1 file changed, 68 insertions(+), 68 deletions(-)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 3487be79847c..f625f65c286f 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> 
> Most of the patch is OK IMO, but not the intel_pstate part:
> The 2-space extra indents work fine here, while the extra tab makes a lot of the
> lines go beyond the 80-column mark.
> 
> > @@ -1650,39 +1650,39 @@
> >  			0	disables intel_idle and fall back on acpi_idle.
> >  			1 to 9	specify maximum depth of C-state.
> >  
> > -	intel_pstate=  [X86]
> > -		       disable
> > -		         Do not enable intel_pstate as the default
> > -		         scaling driver for the supported processors
> > -		       passive
> > -			 Use intel_pstate as a scaling driver, but configure it
> > -			 to work with generic cpufreq governors (instead of
> > -			 enabling its internal governor).  This mode cannot be
> > -			 used along with the hardware-managed P-states (HWP)
> > -			 feature.
> > -		       force
> > -			 Enable intel_pstate on systems that prohibit it by default
> > -			 in favor of acpi-cpufreq. Forcing the intel_pstate driver
> > -			 instead of acpi-cpufreq may disable platform features, such
> > -			 as thermal controls and power capping, that rely on ACPI
> > -			 P-States information being indicated to OSPM and therefore
> > -			 should be used with caution. This option does not work with
> > -			 processors that aren't supported by the intel_pstate driver
> > -			 or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
> > -		       no_hwp
> > -		         Do not enable hardware P state control (HWP)
> > -			 if available.
> > -		hwp_only
> > -			Only load intel_pstate on systems which support
> > -			hardware P state control (HWP) if available.
> > -		support_acpi_ppc
> > -			Enforce ACPI _PPC performance limits. If the Fixed ACPI
> > -			Description Table, specifies preferred power management
> > -			profile as "Enterprise Server" or "Performance Server",
> > -			then this feature is turned on by default.
> > -		per_cpu_perf_limits
> > -			Allow per-logical-CPU P-State performance control limits using
> > -			cpufreq sysfs interface
> > +	intel_pstate=	[X86]
> > +			disable
> > +				Do not enable intel_pstate as the default
> > +				scaling driver for the supported processors
> > +			passive
> > +				Use intel_pstate as a scaling driver, but configure it
> > +				to work with generic cpufreq governors (instead of
> > +				enabling its internal governor).  This mode cannot be
> > +				used along with the hardware-managed P-states (HWP)
> > +				feature.
> > +			force
> > +				Enable intel_pstate on systems that prohibit it by default
> > +				in favor of acpi-cpufreq. Forcing the intel_pstate driver
> > +				instead of acpi-cpufreq may disable platform features, such
> > +				as thermal controls and power capping, that rely on ACPI
> > +				P-States information being indicated to OSPM and therefore
> > +				should be used with caution. This option does not work with
> > +				processors that aren't supported by the intel_pstate driver
> > +				or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
> > +			no_hwp
> > +				Do not enable hardware P state control (HWP)
> > +				if available.
> > +			hwp_only
> > +				Only load intel_pstate on systems which support
> > +				hardware P state control (HWP) if available.
> > +			support_acpi_ppc
> > +				Enforce ACPI _PPC performance limits. If the Fixed ACPI
> > +				Description Table, specifies preferred power management
> > +				profile as "Enterprise Server" or "Performance Server",
> > +				then this feature is turned on by default.
> > +			per_cpu_perf_limits
> > +				Allow per-logical-CPU P-State performance control limits using
> > +				cpufreq sysfs interface
> >  
> >  	intremap=	[X86-64, Intel-IOMMU]
> >  			on	enable Interrupt Remapping (default)
> > @@ -2027,7 +2027,7 @@
> >  			* [no]ncqtrim: Turn off queued DSM TRIM.
> >  
> >  			* nohrst, nosrst, norst: suppress hard, soft
> > -                          and both resets.
> > +			and both resets.
> 
> I would leave that line above indented like the one after "rstonce" below.
> 
> >  
> >  			* rstonce: only attempt one reset during
> >  			  hot-unplug link recovery
> 
> 
> -- 
> ~Randy

Okay, thanks for your feedback.

I reindented intel_pstate as you said and I can still see the whole
description for the 'advanced' option is going past the 80-column mark.

I'll leave it indented with two spaces for this patch.
If you wish I can make a separate patch that addresses 80-column overrun
for intel_pstate.

I'll indent the nohrst,... section like rstonce.

Does that sound good to you?

-Thymo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ