> > 20121114-04.patch: > >> - * dmextern > >> + * dmdeferred > >> +acpi_status acpi_dm_parse_deferred_ops(union acpi_parse_object > >> +*root); > >> +/* > >> + * dmextern > >> + */ > >> -acpi_status acpi_dm_is_resource_template(union acpi_parse_object > >> *op); > >> +acpi_status > >> +acpi_dm_is_resource_template(struct acpi_walk_state *walk_state, > >> + union acpi_parse_object *op); > > < acpi_walk_aml_callback user_function, > > < void **context); > >> acpi_walk_aml_callback user_function, void *context); > > < acpi_walk_aml_callback user_function, void **context) > >> acpi_walk_aml_callback user_function, void *context) > > < (void **)end_tag); > >> end_tag); > > 10 lines are caused by lacking of acdisasm.h and 7 lines are caused by (void **) > fixes. The latter will be seen in the next acpica release which is not what I'm > worrying about. > > I just care about the acdisasm.h, if it is included, my life can be easier and it > will not be a trouble for the developers currently using ACPICA in the > community. > > But Len has told you very clearly not to include it. This is not a Len's whim, > there's a reason for that. > > Is the reason not known to you or don't you agree with it? I agreed w/ what we've been discussing about and reworked then found this. I just wonder whether we could think about it from a different perspective. Now we have the directory-by-directory "exceptions" maintained in the release scripts: common/compiler/debugger/disassembler/interpreter/os_specific/tools. I just wonder do we need to maintain the file-by-file "exceptions" for the release process. It will be convenient if there's no such exceptions, then ACPICA can freely manage the files under the "white listed" directories. Best regards -Lv -- 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
