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: <20090206151027.GC13758@n2100.arm.linux.org.uk>
Date:	Fri, 6 Feb 2009 15:10:27 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Jaswinder Singh Rajput <jaswinder@...nel.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tony Luck <tony.luck@...el.com>,
	Sam Ravnborg <sam@...nborg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	hskinnemoen@...el.com, cooloney@...nel.org, ralf@...ux-mips.org,
	dhowells@...hat.com, matthew@....cx, chris@...kel.net,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull -tip] headers_check fixes for other architectures

On Fri, Feb 06, 2009 at 08:30:07PM +0530, Jaswinder Singh Rajput wrote:
> On Fri, 2009-02-06 at 14:51 +0000, Russell King - ARM Linux wrote:
> > > > 
> > > > So no point including this file in assembly with this patch - the ifndef
> > > > disables the entire file.
> > > 
> > > Truth Table of linux/types.h :
> > > 
> > > If Assembly then N
> > > otherwise Y
> > > 
> > > what your table says.
> > 
> > If the entire file is not suitable for assembly, don't include the file
> > in assembly files.  Nice and simple, and no need to add additional ifdefs.
> 
> Ahh, so your truth table says:
> 
> If Assembly then make different header files
> If C then make another header files

No.  My point is exactly as I stated above, please don't twist my
statement into something that it isn't.

Taking this further, if you're including linux/types.h into another
header file, you're including it because you want some C type from
that or an included file.  Use of that type is also not ASM friendly,
so the use is going to have to be excluded by ifndef in that header.

So why not do as we *already* do and ensure that the linux/types.h
inclusion happens within that section.

Why change the rules?
--
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