linux-kernel - Re: [git pull request] ACPI Processor Aggregator Driver for 2.6.32-rc1

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, 5 Oct 2009 16:23:12 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Len Brown <lenb@...nel.org>, rjw@...k.pl,
	balbir@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org, a.p.zijlstra@...llo.nl,
	shaohua.li@...el.com, svaidy@...ux.vnet.ibm.com
Subject: Re: [git pull request] ACPI Processor Aggregator Driver for
 2.6.32-rc1

On Mon, 5 Oct 2009, Andrew Morton wrote:
> 
> But it's all too late now, isn't it.  This is the first time that
> non-linux-acpi readers knew of the existence of this driver.

Why do people even care? This driver is not going to be used in any 
situation where any regular person will _ever_ care. And if you don't 
like it, you don't have to enable it at all.

That driver is ACPI-specific, is not very complex, is marked EXPERIMENTAL, 
and everybody including Len has said that _if_ the scheduler people can 
ever solve it at that level, it would be good. But as it is, it has 
NOTHING to do with the scheduler, and why _should_ any non-ACPI people 
know about the existence of that driver?

In fact, the only reason the scheduler people even know about it is that 
Len at first tried to do something more invasive, and was shot down. Now 
it's just a driver, and the scheduler people can _try_ to do it some other 
way if they really care, but that's _their_ problem. Not the driver.

In the meantime, I personally suspect we probably never want to even try 
to solve it in the scheduler, because why the hell should we care and add 
complex logic for something like that? At least not until we end up having 
the same issue on some other architecture too, and it turns from a hacky 
ACPI thing into something more.

As it is, the driver is entirely self-contained and doesn't affect any 
other subsystem. 

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