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: <200705311556.17966.lenb@kernel.org>
Date:	Thu, 31 May 2007 15:56:17 -0400
From:	Len Brown <lenb@...nel.org>
To:	"Pekka Enberg" <penberg@...helsinki.fi>
Cc:	trenn@...e.de, linux-acpi <linux-acpi@...r.kernel.org>,
	"Andrew Morton" <akpm@...l.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ACPI Debug - for test, devel and possibly even for production kernels

On Thursday 31 May 2007 14:57, Pekka Enberg wrote:
> On 5/31/07, Thomas Renninger <trenn@...e.de> wrote:
> > (This should efficiently be the same as the proposed big patch a year
> > ago from Pekka Enberg, just a bit smaller and should make ACPICA and
> > kernel/linux people happy:
> > http://marc.info/?l=linux-kernel&m=113699535303722&w=2)
> 
> No, you're keeping these obfuscating macros around:
> 
> +#define return_VOID                     return
> +#define return_ACPI_STATUS(s)           return(s)
> +#define return_VALUE(s)                 return(s)
> +#define return_UINT8(s)                 return(s)
> 
> Making the ACPI code look like regular Linux kernel code (or even
> regular C for that matter) was the whole point of my patch. Your patch
> doesn't change that.

I think that Thomas's point is that he is optimally removing
function tracing via #ifdef.
Your 600KB patch, on the other hand, permanently removed the feature
and touched every file in ACPICA.

The net effect to the user is the same, the ability to enable
ACPI_DEBUG and not enable ACPICA function tracing.

As I probably wrote a year ago, it isn't viable to completely
remove the tracing code --
until Linux reaches a point where vendors certify that their
BIOS is compatible with Linux before they ship, rather than the Linux
community having to debug some Windows-compatible systems into
Linux-compatibility well after they have shipped into the field.

-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ