Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1363837 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212 release Lv Zheng <lv.zheng@intel.com> - 2016-03-24 02:40 +0100
    Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212  release Joe Perches <joe@perches.com> - 2016-03-24 02:50 +0100
      RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212  release "Zheng, Lv" <lv.zheng@intel.com> - 2016-03-24 07:20 +0100
        RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212  release "Brown, Len" <len.brown@intel.com> - 2016-03-24 07:40 +0100
          RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212  release "Zheng, Lv" <lv.zheng@intel.com> - 2016-03-24 08:00 +0100
        Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212  release Joe Perches <joe@perches.com> - 2016-03-24 12:10 +0100
          RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212  release "Zheng, Lv" <lv.zheng@intel.com> - 2016-03-28 05:10 +0200
            Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212  release Joe Perches <joe@perches.com> - 2016-03-28 05:20 +0200
              RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212  release "Zheng, Lv" <lv.zheng@intel.com> - 2016-03-29 07:40 +0200
                Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212  release Joe Perches <joe@perches.com> - 2016-03-29 08:00 +0200

#1363837 — [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212 release

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.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
---
 drivers/acpi/acpica/hwregs.c |    2 +-
 drivers/acpi/acpica/nsinit.c |    1 -
 drivers/acpi/acpica/nsload.c |    2 +-
 drivers/acpi/osl.c           |    2 +-
 include/acpi/acpiosxf.h      |    2 +-
 5 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index 5ba0498..93f8831 100644
--- 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)
 {
 	u64 address;
 	u64 value64;
diff --git a/drivers/acpi/acpica/nsinit.c b/drivers/acpi/acpica/nsinit.c
index d4aa8b6..2de8adb 100644
--- a/drivers/acpi/acpica/nsinit.c
+++ b/drivers/acpi/acpica/nsinit.c
@@ -602,7 +602,6 @@ acpi_ns_init_one_device(acpi_handle obj_handle,
 	info->flags = ACPI_IGNORE_RETURN_VALUE;
 
 	status = acpi_ns_evaluate(info);
-
 	if (ACPI_SUCCESS(status)) {
 		walk_info->num_INI++;
 	}
diff --git a/drivers/acpi/acpica/nsload.c b/drivers/acpi/acpica/nsload.c
index 75cdb87..b5e2b0a 100644
--- a/drivers/acpi/acpica/nsload.c
+++ b/drivers/acpi/acpica/nsload.c
@@ -123,8 +123,8 @@ acpi_ns_load_table(u32 table_index, struct acpi_namespace_node *node)
 		(void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
 		acpi_ns_delete_namespace_by_owner(acpi_gbl_root_table_list.
 						  tables[table_index].owner_id);
-		acpi_tb_release_owner_id(table_index);
 
+		acpi_tb_release_owner_id(table_index);
 		return_ACPI_STATUS(status);
 	}
 
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 814d5f8..bef06c9 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -582,7 +582,7 @@ static char acpi_os_name[ACPI_MAX_OVERRIDE_LEN];
 
 acpi_status
 acpi_os_predefined_override(const struct acpi_predefined_names *init_val,
-			    char **new_val)
+			    acpi_string *new_val)
 {
 	if (!init_val || !new_val)
 		return AE_BAD_PARAMETER;
diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h
index d1e34d1..dfdcf5a 100644
--- a/include/acpi/acpiosxf.h
+++ b/include/acpi/acpiosxf.h
@@ -96,7 +96,7 @@ acpi_physical_address acpi_os_get_root_pointer(void);
 #ifndef ACPI_USE_ALTERNATE_PROTOTYPE_acpi_os_predefined_override
 acpi_status
 acpi_os_predefined_override(const struct acpi_predefined_names *init_val,
-			    char **new_val);
+			    acpi_string * new_val);
 #endif
 
 #ifndef ACPI_USE_ALTERNATE_PROTOTYPE_acpi_os_table_override
-- 
1.7.10

[toc] | [next] | [standalone]

#1363854 — 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.

> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
[]
> @@ -582,7 +582,7 @@ static char acpi_os_name[ACPI_MAX_OVERRIDE_LEN];
>  
>  acpi_status
>  acpi_os_predefined_override(const struct acpi_predefined_names *init_val,
> -			    char **new_val)
> +			    acpi_string *new_val)

And here:

acpi_string pointer style 1:

> diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h
[]
> @@ -96,7 +96,7 @@ acpi_physical_address acpi_os_get_root_pointer(void);
>  #ifndef ACPI_USE_ALTERNATE_PROTOTYPE_acpi_os_predefined_override
>  acpi_status
>  acpi_os_predefined_override(const struct acpi_predefined_names *init_val,
> -			    char **new_val);
> +			    acpi_string * new_val);

acpi_string pointer style 2:

There are varying styles for acpi_string *

So far, this just looks sloppy.
Should the rest be reviewed?

[toc] | [prev] | [next] | [standalone]

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

Hi,

First, thanks for the revew.

> From: Joe Perches [mailto:joe@perches.com]
> 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.

> 
> > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> []
> > @@ -582,7 +582,7 @@ static char
> acpi_os_name[ACPI_MAX_OVERRIDE_LEN];
> >
> >  acpi_status
> >  acpi_os_predefined_override(const struct acpi_predefined_names *init_val,
> > -			    char **new_val)
> > +			    acpi_string *new_val)
> 
> And here:
> 
> acpi_string pointer style 1:
[Lv Zheng] 
This file drivers/acpi/osl.c is not in the ACPICA upstream.
It is Linux specific, so we use Linux coding style.
Thus this is a result of a "human".

> 
> > diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h
> []
> > @@ -96,7 +96,7 @@ acpi_physical_address acpi_os_get_root_pointer(void);
> >  #ifndef ACPI_USE_ALTERNATE_PROTOTYPE_acpi_os_predefined_override
> >  acpi_status
> >  acpi_os_predefined_override(const struct acpi_predefined_names *init_val,
> > -			    char **new_val);
> > +			    acpi_string * new_val);
> 
> acpi_string pointer style 2:
> 
> There are varying styles for acpi_string *
[Lv Zheng] 
This is ACPICA upstream file modification.
Also a result of a "process".

> 
> So far, this just looks sloppy.
[Lv Zheng] 
As I said, please ignore "process" issues.
I need them to be wrong in order not to modify every "process" generated patches manually.
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.

> Should the rest be reviewed?

[Lv Zheng] 
Yes, please.

Thanks and best regards
-Lv

[toc] | [prev] | [next] | [standalone]

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

> > >
> > > -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.

I disagree.

The patch should be correct when it hits the Linux kernel tree.

If the process is broken, then fix the process and re-send
a fixed patch.  Linux doesn't care if the process is a program
that runs with the click of a button, or the result of 1000
engineering laboring day and night. Only the result matters,
the result should be correct, and this patch is not correct.

-Len

[toc] | [prev] | [next] | [standalone]

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

Hi,

> From: Brown, Len
> Subject: RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212
> release
> 
> > > >
> > > > -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.
> 
> I disagree.
> 
> The patch should be correct when it hits the Linux kernel tree.
[Lv Zheng] 
This has already been an agreement between Linux and ACPICA.
We have 1 such kind of patch in each release cycle merged.

> 
> If the process is broken, then fix the process and re-send
> a fixed patch.  Linux doesn't care if the process is a program
> that runs with the click of a button, or the result of 1000
> engineering laboring day and night. Only the result matters,
> the result should be correct, and this patch is not correct.
[Lv Zheng] 
If we forced the rule you mentioned, then every release cycle would be blocked by strange reasons.
It's worse than letting this pass.
Normally, ACPICA release happens before the indent issue is identified.
So the patch to fix the indent issue will be merged in ACPICA upstream after the release cycle.
Then if we let the machine do this automatically, the fix will appear after the release cycle.

Moreover, sometimes, such indent issue is not in the process itself.
Though we use indent -linux, but indent doesn't work as our expectation to generate a patch that can pass checkpatch.pl.
What should we do then?
We are developing Linux kernel, not developing indent.
So sometimes, such kind of issue is inevitable as long as we use "indent".
It's useless to waste time working on correcting this.
Which means humans are hired to do machine's job...

Thanks and best regards
-Lv

[toc] | [prev] | [next] | [standalone]

#1364076 — 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@perches.com]
> > 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

> 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?

[toc] | [prev] | [next] | [standalone]

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

Hi,

> From: linux-acpi-owner@vger.kernel.org [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@perches.com]
> > > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1365287 — Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212 release

On Mon, 2016-03-28 at 03:02 +0000, Zheng, Lv wrote:
> Hi,

Hello.

> > 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.

Good guess.

The "maybe add something like" should give you a clue.

> You need to pull ACPICA repo and do the followings to confirm if this is working:

No, I disagree.  _I_ don't need to.  You need to.

You shouldn't have a process that generates defective patches
and then sends them to the list.

cheers, Joe

[toc] | [prev] | [next] | [standalone]

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

Hi,

> From: Joe Perches [mailto:joe@perches.com]
> Subject: Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212
> release
> 
> On Mon, 2016-03-28 at 03:02 +0000, Zheng, Lv wrote:
> > Hi,
> 
> Hello.
> 
> > > 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.
> 
> Good guess.
> 
> The "maybe add something like" should give you a clue.
> 
> > You need to pull ACPICA repo and do the followings to confirm if this is
> working:
> 
> No, I disagree.  _I_ don't need to.  You need to.
[Lv Zheng] 
Then you don't have to provide the solution as you are not the one executing the process.
I can fix it myself:
https://github.com/acpica/acpica/pull/129 
It would be merged by the ACPICA upstream in the near future.

I'll show you the difficulties of "process" later.

> 
> You shouldn't have a process that generates defective patches
> and then sends them to the list.
[Lv Zheng] 
You are not the one executing this process, so you don't know what's happening here.

Actually the Linux repo should be synced to the state of the ACPICA repo.
The defective patch is used for "syncing repo state", not for "fixing indentation problem" or something else.
So if we merged a "process fixing commit" into ACPICA upstream, you'll still have to see such kind of defective patches before this commit because of the state synchronization requirement.

There have already been many such indentation conflicts between Linux and ACPICA.
My current rule on the existing unsynced Linux side code conflict is based on the "syncing repo state" purpose:
I'll ignore them as long as no new linuxized ACPICA commits complain merge conflicts.
But if I saw merge conflict to a new linuxized commit, I'll revert the Linux side code to the __wrong__ but synced state in a separate patch.
That's why you can see this commit.

As a conclusion, the defective patch is because of the purpose - syncing repo state.
Then why do I use a separate patch?

The separated defective patch is the only patch we need to maintain manually, and all other linuxized ACPICA results needn't be maintained manually.
So you can imagine that we can do the recursive development/testing in the ACPICA upstream again and again.
And the linuxizing result should always require no human intervention as long as they can appear after the defective patch.

I have several situations for you to know my work flow.
1. ACPICA release
If this is not separated, then I should merge part of the defective patch into the new linuxized ACPICA commit that generates the merge conflict.
This is a kind of so called "human intervention".
Then if a bug was found after the release testing work (may take several days) was done, I would have to linuxize the whole series again after fixing the bug from the ACPICA upstream.
This results in a redo of the "human intervention". And this kind of "human intervention" may spread to all commits after the fixed one.
Furthermore, the "human intervention" could happen again and again during the recursive release testing process.

There are similar cases:
2. Fast path ACPICA commits
We have something that can't be confirmed from ACPICA development environment, and they need to go Linux repo first.
Such kind of patch series also contain such a separated defective patch.
If this is not separated, then since the series need to be rebased again and again during the development process (because of bug fixing or Linux upstream sync).
Then the "human intervention" need to be performed again and again.

3. The "process fixing commit"
If this problem is fixed, I need the Linux side correction to happen only when this commit is about to enter linux repo.
Otherwise, all commits between the merge point of this commit and the current repo head need "human interventions".
Sometimes, these commits need to be linuxized and posted on the Bugzilla/community to have users to test them.
As the working kernel of the reporters or the developers are different, the "human interventions" have to be performed again and again for them.
And there will be many different versions of such kind of linuxized ACPICA patch series. 
It's not convenient for everyone.

So you can sense, the workload of the "human intervention" depends on the following 2 facts:
1. How worse the "unsynced state" is in the current Linux repo, and this also depends on how big the linuxized "process fixing commit" will be.
2. The merge timing of the "process fixing commit" where the state should be synced and the merge timing of other unsynced commits that could happen before this synced point.

I cannot control the merge timing of the "process fixing commit" and the merge timing of other unsynced commits.
So I have to control the "unsynced state" otherwise my bandwidth will be easily filled up by the "human intervention" due to the uncontrollable "merge timings".
You can easily imagine that my every work minutes will be filled up with the "human intervention" if I cannot control the "unsynced state".
This is a kind of job for a machine, while you are forcing me to be a machine by simply saying: it's my business, not yours...
Is that worthy? Should I allocate more bandwidth to work on real issues rather than doing the "human intervention" with such a heavy load?

The above is a justification for why I was thinking I had already obtained the agreement or the forgiveness from Linux upstream to generate such kind of defective patch to make my life easier.

Thanks and best regards
-Lv

[toc] | [prev] | [next] | [standalone]

#1365874 — Re: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212 release

On Tue, 2016-03-29 at 05:37 +0000, Zheng, Lv wrote:
> Hi,

Hi again.
> > No, I disagree.  _I_ don't need to.  You need to.
> [Lv Zheng] 
> Then you don't have to provide the solution as you are not the one executing the process.
> I can fix it myself:
> https://github.com/acpica/acpica/pull/129 
> It would be merged by the ACPICA upstream in the near future.

Excellent, thank you.

For this: https://github.com/acpica/acpica/pull/129/commits/b2294cae776f5a66a7697414b21949d307e6856f

Maybe you could use \w+ instead of [_a-zA-Z0-9]+

> I'll show you the difficulties of "process" later.

ok, appreciate your time.

> > You shouldn't have a process that generates defective patches
> > and then sends them to the list.
> [Lv Zheng] 
> You are not the one executing this process, so you don't know what's happening here.

True.

> Actually the Linux repo should be synced to the state of the ACPICA repo.

That's more doubtful, but then again I don't maintain
ACPICA and you do.

cheers, Joe

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web