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]
Message-ID: <1A7043D5F58CCB44A599DFD55ED4C94846A17FF0@fmsmsx115.amr.corp.intel.com>
Date:	Thu, 24 Mar 2016 06:35:44 +0000
From:	"Brown, Len" <len.brown@...el.com>
To:	"Zheng, Lv" <lv.zheng@...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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ