linux-kernel - Re: [linux-pm] [PATCH 16/18] 2.6.40: x86 idle APM: remove deprecated apm_cpu

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]

Date:	Mon, 4 Apr 2011 11:05:58 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Trinabh Gupta <trinabh@...ux.vnet.ibm.com>
Cc:	Len Brown <lenb@...nel.org>, Len Brown <len.brown@...el.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] [PATCH 16/18] 2.6.40: x86 idle APM: remove
 deprecated apm_cpu_idle()

> There are other problems too. This design of pm_idle has been copied
> by numerous other architectures. arm/blackfin/cris/ia64/m32r/m68knomm
> /microblaze/mn10300/sh/sparc all have pm_idle. This will keep spreading
> in future I guess.

Presumably because they've decided it is a good model and works for them.
That's a matter for their arch maintainers surely.

> https://lkml.org/lkml/2010/10/19/449 . The problem  is that it
> results in two places of registration: cpuidle subsystem and
> this. It was pointed that 99.99% of people run cpuidle and
> we should directly call cpuidle and use its registration mechanism
> rather than duplicate code.

That makes sense. However what Len is trying to do doesn't seem to.

The most likely case is nobody really needs APM idle now. In which case
Len's first patches (adding the warnings) make sense, but instead of
rushing headlong into everything else a simple years wait until the WARNs
have been in Fedora and co for a few months would avoid any further work
on it. In the mean time it produces a WARN, it can even be marked
__deprecated to ensure nobody else uses it.

The less likely case is that at some point within the year it turns out a
few people do need and care about it, so it needs shuffling into cpuidle
nicely.

In computing terms this seems to be a lazy evaluation problem - why do
all the extra work and risk bugs and problems trying to do things within
one release when you can just let it chill for a year and maybe not do
any work at all ?

Don't let me stop anyone actually doing the work but it seems to be
impatience before sanity ?

Alan
--
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/