RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212 release

[Zheng, Lv]

Hi,

> From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi-
> Subject: Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212
> release
> 
> On Thu, 2016-03-24 at 06:19 +0000, Zheng, Lv wrote:
> > From: Joe Perches [mailto:joe@xxxxxxxxxxx]
> > > Subject: Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for
> 20160212
> > > release
> > >
> > > On Thu, 2016-03-24 at 09:38 +0800, Lv Zheng wrote:
> > > >
> > > > The patch reduces source code differences between the Linux kernel and
> the
> > > > ACPICA upstream so that the linuxized ACPICA 20160212 release can be
> > > > applied with reduced human intervention.
> > > In the very first patch fragment:
> > > > diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
> > > []
> > > > @@ -152,7 +152,7 @@ acpi_hw_validate_register(struct
> > > acpi_generic_address *reg,
> []
> > > > -acpi_status acpi_hw_read(u32 *value, struct acpi_generic_address *reg)
> > > > +acpi_status acpi_hw_read(u32 *value, struct acpi_generic_address * reg)
> > > The second argument * style appears the opposite of normal style
> > > and a different style than the first argument * style.
> > [Lv Zheng]
> > The file is drivers/acpi/acpica/hwregs.c, which is coming from ACPICA
> upstream.
> > So this is a result of "ACPICA release".
> > In other words, this is a result of a "process".
> > In order to fix this, things need to be done in "ACPICA release scripts".
> > Which should be done in
> https://github.com/acpica/acpica/blob/master/generate/linux/libacpica.sh.
> > Otherwise, "ACPICA release" process will require human intervention.
> >
> > So please leave this patch fragment as is.
> > It will be automatically fixed if the "ACPICA release" process is fixed.
> > And if you don't leave this fragment as is, the "ACPICA release" process will
> get hurt.
> []
> > please ignore "process" issues.
> > I need them to be wrong in order not to modify every "process" generated
> patches manually.
> 
> So why not fix the process script first?
> 
> Maybe add something like:
> 
> $ grep -E "^typedef\s+\w+\s*\*?\s*acpi_\w+" include/acpi/actypes.h | \
>   grep -Eoh "\bacpi_\w+"
> 
> to the acpi_types variable in the lindent_single function
[Lv Zheng] 
I don't think this can work given:
1. we are not only dealing with typedefs, but structs, struct xxx will be converted into types during the release process.
2. we have only upper cased type names in ACPICA upstream, but have the lower cased type names in Linux, and this doesn't solve that.
So I guess you didn't test your idea.

You need to pull ACPICA repo and do the followings to confirm if this is working:
A. generate the diff
# git clone <acpica repo>
# git commit your change
# ./generate/linux/gen-patch.pl HEAD
You can confirm how big a change will be resulted by your idea.
And you can confirm if the change can really solve this issue.

B. apply the diff
Then you can try to apply the linuxized patch to the linux repo to see how many jobs are still needed.
Then you should be able to determine if this is worthy to happen during a release cycle...

That's why I agree we need to solve this, but don't agree to solve this during a release cycle.

Thanks
-Lv

> 
> > You can find many such kind of indent issues in drivers/acpi/acpica,
> include/acpi, tools/power/acpi.
> > They are there for good reasons.
> > I'll cleanup such issues from "ACPICA release" process.
> 
> Any idea when?
> 
> --
> 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