* 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
