devel@xxxxxxxxxx >-----Original Message----- >From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] >Sent: Monday, May 12, 2008 11:57 PM >To: Moore, Robert >Cc: lenb@xxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; trenn@xxxxxxx; linux- >acpi@xxxxxxxxxxxxxxx >Subject: RE: [patch 05/10] acpi: use __init* oneverythingintables/tbfadt.c > >Thanks, Robert! So for future changes like this (if any) I suppose they >would >be preferred to be directly against acpica? What mailing list would they go >to? Jan > >>>> "Moore, Robert" <robert.moore@xxxxxxxxx> 09.05.08 22:04 >>> >Jan, > >I've integrated your const and macro changes into the acpica source. > >Thanks for your help, >Bob > > >>-----Original Message----- >>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] >>Sent: Friday, May 02, 2008 12:43 PM >>To: trenn@xxxxxxx >>Cc: Moore, Robert; lenb@xxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; linux- >>acpi@xxxxxxxxxxxxxxx >>Subject: Re: [patch 05/10] acpi: use __init* on >everythingintables/tbfadt.c >> >>>>> Thomas Renninger <trenn@xxxxxxx> 05/01/08 8:55 PM >>> >>>Andrew, IMO you can drop this and the const cleanups from -mm tree. >>> >>>Jan, nearly all code in: >>>drivers/acpi/*/*.[hc] >>>is part of ACPICA. This currently still is (may change) an Intel >>>internal repository which gets synced to several OS implementations, >>>also Linux. __init does not exist there (yet). >> >>I'm fairly sure I saw __init used elsewhere in ACPI CA code, so I >>didn't think adding mode stuff like this would cause problems (as >>long as the changes were correct of course). >> >>>Also the const changes may be a bit of a pain -> this is what Robert >>>meant with as long as it won't end in a chain of const cleanups :) >> >>Of course they're a pain now. But see below. >> >>>The whole code gets style cleaned up through Lindent and manually to >>>half way fit to the Linux kernel style when things get merged. >>> >>>Currently Robert has to readjust this to ACPICA coding style by hand >>>and merge it into the internal Intel repository. Len has to pick it up >>>somewhat later and merge it back to the Linux kernel... >>> >>>Therefore I expect for cleanup patches (this one is on the edge, but I >>>could understand Intel if they hold it off) the best is to wait until >>>Intel publishs ACPICA as CVS or whatever repository on their >>>lesswatts.org site. >> >>That's brave to say - I've been seeing this kind of significant cleanup >>potential about seven years ago (when I wasn't dealing with ACPI CA >>on Linux, yet), so I have to admit I find it a little odd (at least) to >>defer >>this even further - the code should have been written const-correct >>and __init-ready (iirc Windows also has a concept of init code) from >>the beginning in my opinion. ANyway, the purpose of both patches >>was to try and get this cleanup started in Linux or at least turn >>attention to this on the ACPI CA side. >> >>Jan -- 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
