linux-kernel - Re: [PATCH 03/15] ACPICA: move common private headers under kernel/acpi/acpica/

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: <20090107221017.GD17917@elte.hu>
Date:	Wed, 7 Jan 2009 23:10:17 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Len Brown <lenb@...nel.org>
Cc:	linux-acpi@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 03/15] ACPICA: move common private headers under
	kernel/acpi/acpica/

* Len Brown <lenb@...nel.org> wrote:

> > If it goes there then IMHO the ACPI code needs to be cleaned up 
> > _significantly_ to not wrap native Linux calls like spinlocks, 
> > allocators, etc.
> 
> Are there different style guidelines for the src/kernel/
> directory versus other parts of the source tree?
> 
> The acpi/acpica/ sub-directory is a processed version of code that we 
> share with BSD, opensolaris, and every ACPI-capable OS on Earth besides 
> Microsoft's.  There is a huge commmon benefit to that sharing, and the 
> Linux community's tolerance of wrappers, shims, and other unconventional 
> things allows that sharing to work without an infinite amount of 
> additional make-work.

i still tend to regard kernel/* as the core Linux kernel, as code that can 
be improved infinitely (only subject to the laws of physics), without 
having to worry about how the ACPI spec wants certain things done.

The moment you bring in "this has to work on BSD, etc." arguments it will 
be a never ending excuse for crap. Standards tend to create the _worst_ 
possible code, because every vendor compromizes a bit on another vendor's 
crap, just to be able to get in their own important crap. So the more 
vendors there are in a standards group, the crappier the end result is 
technically.

Also, ACPI is an environment/bootstrap detail well placed under 
drivers/acpi/ - why should it move to kernel/acpi/ ? The fact that it's 
used widely is immaterial - by that argument we could move arch/x86/ to 
kernel/x86/, and we could move drivers/ata/ to kernel/ata/ as well. (they 
are probably even more widely deployed than ACPI)

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