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: <Pine.LNX.4.64.0610071042220.3952@g5.osdl.org>
Date:	Sat, 7 Oct 2006 10:49:42 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Al Viro <viro@....linux.org.uk>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] minimal alpha pt_regs fixes



On Sat, 7 Oct 2006, Jeff Garzik wrote:
> 
> ACK, of course, but I wonder if we can do something about these 1-line header
> files.
> 
> Would it be reasonable to encourage developers to do something like
> 
> 	#ifdef ARCH_HAVE_FEATURE_FOO
> 	#include <asm/foo.h>
> 	#else
> 	#include <asm-generic/foo.h>
> 	#endif
> 
> to avoid these 1-line headers?

I actually think that _unconditional_ simple code is much nicer than 
conditional one.

With the current setup, we have a number of one-line trivial headers 
(which actually could be symlinks - the only downside of that is that 
regular "patch" doesn't really know about them, even if git does, and can 
handle them, including the "extended git patch" format). They are 
unconditional, so following them never implies having to grep for 
different architectures doing different things.

I personally absolutely detest the "ARCH_HAVE_FEATURE_FOO" kind of thing 
that makes different architectures behave differently. I'd much rather 
have a few small and simple files that all look the same and are totally 
obvious, except for the odd architecture that actually caused the 
arch-split in the first place.

(Also, if the files really _are_ entirely identical, at least it won't add 
any overhead at all to git - they'll all use the same backing store)

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