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]
Message-Id: <200708140157.15545.lenb@kernel.org>
Date:	Tue, 14 Aug 2007 01:57:15 -0400
From:	Len Brown <lenb@...nel.org>
To:	Randy Dunlap <randy.dunlap@...cle.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: ACPI: thermal: create "thermal.off=1" to disable ACPI thermal support

On Sunday 12 August 2007 14:49, Randy Dunlap wrote:
> On Sun, 12 Aug 2007 10:59:11 GMT Linux Kernel Mailing List wrote:
> 
> > Gitweb:     http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=72b33ef8bb1ac7f6c5a16d23304ab25ddc73d93d
> > Commit:     72b33ef8bb1ac7f6c5a16d23304ab25ddc73d93d
> > Parent:     3864e8ccbba1dcdea87398ab80fdc8ae0fab7c45
> > Author:     Len Brown <len.brown@...el.com>
> > AuthorDate: Sun Aug 12 00:12:17 2007 -0400
> > Committer:  Len Brown <len.brown@...el.com>
> > CommitDate: Sun Aug 12 00:12:17 2007 -0400
> > 
> >     ACPI: thermal: create "thermal.off=1" to disable ACPI thermal support
> >     
> >     "thermal.off=1" disables all ACPI thermal support at boot time.
> >     
> >     CONFIG_ACPI_THERMAL=n can do this at build time.
> >     "# rmmod thermal" can do this at run time,
> >     as long as thermal is built as a module.
> >     
> >     WARNING: On some systems, disabling ACPI thermal support
> >     will cause the system to run hotter and reduce the
> >     lifetime of the hardware.
> >     
> >     Signed-off-by: Len Brown <len.brown@...el.com>
> > ---
> >  Documentation/kernel-parameters.txt |    3 +++
> >  drivers/acpi/thermal.c              |    9 ++++++++-
> >  2 files changed, 11 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> > index 5a62de1..61337d9 100644
> > --- a/drivers/acpi/thermal.c
> > +++ b/drivers/acpi/thermal.c
> > @@ -78,6 +78,10 @@ static int tzp;
> >  module_param(tzp, int, 0);
> >  MODULE_PARM_DESC(tzp, "Thermal zone polling frequency, in 1/10 seconds.\n");
> >  
> > +static int off;
> > +module_param(off, int, 0);
> > +MODULE_PARM_DESC(off, "Set to disable ACPI thermal support.\n");
> > +
> >  static int acpi_thermal_add(struct acpi_device *device);
> >  static int acpi_thermal_remove(struct acpi_device *device, int type);
> >  static int acpi_thermal_resume(struct acpi_device *device);
> 
> Hi,
> 
> What's the purpose of the "\n" in the MODULE_PARM_DESC() string?
> 
> modinfo already terminates module parameter listings with a newline
> after each parameter description.  Some people insert newlines inside
> these strings for pretty printing (which I don't find necessary),
> but using a newline at the end of the string only makes the
> parameter type (that is added by modinfo) appear on a separate line,
> which IMO is worse that having it appear at the end of the parameter
> line.  E.g.,
> 
> $ modinfo -p asus_acpi.ko
> asus_uid:UID for entries in /proc/acpi/asus.
> 
> asus_gid:GID for entries in /proc/acpi/asus.
> 
> $
> 
> but when the newline is omitted, it would be printed as
> 
> $ modinfo -p asus_acpi.ko
> asus_uid:UID for entries in /proc/acpi/asus.
> asus_gid:GID for entries in /proc/acpi/asus.
> $
> 
> 
> or when -p is not used (but only showing the parm lines here):
> 
> $ modinfo asus_acpi.ko
> parm:           asus_gid:GID for entries in /proc/acpi/asus.
>  (uint)
> parm:           asus_uid:UID for entries in /proc/acpi/asus.
>  (uint)
> $
> 
> or if the newline is not used in the string:
> 
> $ modinfo asus_acpi.ko
> parm:           asus_gid:GID for entries in /proc/acpi/asus. (uint)
> parm:           asus_uid:UID for entries in /proc/acpi/asus. (uint)
> $
> 
> where I posit that the latter is better than the former...

Thanks for pointing this out, Randy.
I agree, and have deleted the trailing newlines.

-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ