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] [day] [month] [year] [list]
Date:   Wed, 18 Apr 2018 11:32:03 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Thymo van Beers <thymovanbeers@...il.com>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] docs: kernel-parameters.txt: Fix whitespace

On 04/18/18 11:16, Thymo van Beers wrote:
> 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?

Yes, it does.  Go for it!

thanks,
-- 
~Randy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ