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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Mar 2016 06:53:30 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	"Brown, Len" <len.brown@...el.com>, Joe Perches <joe@...ches.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
CC:	Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: 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