[lkml]   [2009]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 03/15] ACPICA: move common private headers under kernel/acpi/acpica/

* Len Brown <> 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

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)


 \ /
  Last update: 2009-01-07 23:13    [W:0.168 / U:1.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site