linux-kernel - Re: [PATCH 0/9] x86 idle cruft removal

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: <20110331104549.3065ab29@lxorguk.ukuu.org.uk>
Date:	Thu, 31 Mar 2011 10:45:49 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Len Brown <lenb@...nel.org>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-pm@...ts.linux-foundation.org
Subject: Re: [PATCH 0/9] x86 idle cruft removal - v2

> [PATCH 6/9] x86 idle APM: delete apm_cpu_idle(), and its use of pm_idle
> [PATCH 7/9] x86 idle: do not EXPORT_SYMBOL pm_idle and default_idle

I thought someone had agreed to look after APM ?

I'm also curious why you write

"There is some doubt whether the APM idle feature
to call into the BIOS from the idle loop is reliable.
Certainly it was known to fail on some machines,
but more importantly, APM machines have not shipped
for a decade and so finding machines to test the code
is problematic."

We don't care if it doesn't work on a few machines (in fact we have
a table to avoid that), we care that it *DOES* work on lots.

Removing it probably isn't a bad thing long term, but it's not appeared in
the deprecated list and has not been there for several releases so it is
not eligible for removal at this point.

People spent years getting Linux to support all this hardware and
throwing bits out left right and centre to tidy up your current project
is not the way it should be done.

So can we do this properly please. We have a process for good reason.

Deprecate it properly

Add a printk/WARN_ON() indicating to the user it is deprecated but we
will continue, and then give it a couple of releaes. Kerneloops.org will
help answer whether that WARN_ON was hit.

And in the meantime just progress the rest of the work with it present.
If you break APM support by accident doing that then either

a) someone will jump up and down and yell regression - and debug it for
you

or

b) there will be silence because nobody noticed it broke

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/