linux-kernel - Re: [PATCH] PM / sleep: add configurable delay for pm

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: <CAGVrzcZgwQqfBkupWkChYg8NmpKsFzWNa0jB18wN6YUuOzgvsw@mail.gmail.com>
Date:	Sat, 21 Feb 2015 12:25:08 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Brian Norris <computersforpeace@...il.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Len Brown <len.brown@...el.com>,
	Chirantan Ekbote <chirantan@...omium.org>
Subject: Re: [PATCH] PM / sleep: add configurable delay for pm_test

2014-12-17 1:22 GMT-08:00 Pavel Machek <pavel@....cz>:
>
>> > Make it module parameter so that the patch is two lines of code. If
>> > that does not work for you, think of something that does.
>>
>> OK, so that's actually constructive. If lines of code is really the most
>> important factor here, then I suppose I can do that. I'd argue that a
>> module parameter is a much less sensible interface here, though, given
>> that it is coupled with the existing /sys/power/pm_test interface.
>
> If module parameter works for you, we have a winner, that should be
> two lines of code and two lines of documentation.

I do not think that a module parameter is good, some of the uses cases
I can think about (from real people using that facility) involve
setting up a Linux system in a lab with multiple measurement
equipments, having to reboot Linux to change this delay is going to be
a no-go for them because that will break the
uptime/endurance/stability/automated testing they might be doing.
Having them be able to change the PM delay at runtime is completely
satisfactory though.

Both module parameters and sysfs entries need to remain stable, and
potentially there forever, once introduced, yet the sysfs entries are
a lot more flexible.

Considering that Brian's change are enclosed within a CONFIG_PM_DEBUG
ifdef, can we really use the code bloat as a technical argument here?

Thanks!
-- 
Florian
--
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/