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