RE: [patch] ACPI: reduce code size, clean up, fix validator message

["Moore, Robert" <robert.moore@intel.com>]

Everyone should keep in mind that eventually, the ACPICA code can be
fully integrated into each host operating system and then maintained by
the individual OS projects.

During the time that Intel is actively developing and supporting the
ACPICA code, we need the OS-independent interfaces to provide
portability across the dozen or so host operating systems that are
currently supported.

Yes, of course there is some inefficiency in not using the native OS
interfaces. However, this is really the only sane way to support so many
different hosts, and all OS projects get the benefit of debugging help
and feedback from the many different operating systems.

Bob


> -----Original Message-----
> From: Brown, Len
> Sent: Monday, June 26, 2006 10:40 AM
> To: Pavel Machek
> Cc: Ingo Molnar; Andrew Morton; michal.k.k.piotrowski@gmail.com;
> arjan@linux.intel.com; linux-kernel@vger.kernel.org; linux-
> acpi@vger.kernel.org; Moore, Robert; Arjan van de Ven
> Subject: RE: [patch] ACPI: reduce code size, clean up, fix validator
> message
> 
> 
> >Well, gain here is that code actually becomes readable/linux
> >like/something.
> >
> >Feel free to put GPL/BSD license in ACPICA code, saying that by
> >default contributed code is under both licenses.... or something, but
> >having linux-like code under drivers/acpi would be great.
> 
> There is drivers/acpi/*.c
> This is pure GPL and can be as "Linux like" as any purist wants it to
be.
> Indeed, we have several patches in the queue to do just that in
2.6.18.
> 
> and there is drivers/acpi/*/*.c, which is from ACPICA.
> Linux, along with a bunch of other OS's, is downstream.
> 
> The license on ACPICA is not the issue.
> The issue is when we make a syntax change to ACPICA in Linux,
> then it adds to (my) workload to keep Linux up to date with the
upstream
> ACPICA.
> 
> (note that the previous Linux/ACPI maintainer dealt with this issue
>  by simply over-writing the ACPICA files in Linux upon every update.
>  I allow divergence, but I have to track it, it causes merge
conflicts,
>  and Bob and I actively work to change ACPICA upstream to minimize
it.)
> 
> If you have specific feedback on what can be improved,
> I'm certainly willing to listen.  As you may be aware,
> I translate every ACPICA change into Linux format, and
> it is possible that this process can be enhanced.
> 
> Keep in perspective, however, that we have over 200
> functional issues unresolved in bugzilla.kernel.org,
> and spending time on syntax changes is generally
> a lower priority.
> 
> -Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/