Re: [PATCH 03/15] ACPICA: move common private headers underkernel/acpi/acpica/

[Ingo Molnar]

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