Re: [linux-pm] [PATCH 16/18] 2.6.40: x86 idle APM: removedeprecated apm_cpu_idle()

[Alan Cox]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/