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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 25 Feb 2007 06:55:34 -0500
From:	Theodore Tso <tytso@....edu>
To:	Christoph Hellwig <hch@...radead.org>,
	Artem Bityutskiy <dedekind@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Frank Haverkamp <haver@...t.ibm.com>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 05/44 take 2] [UBI] internal common header

On Sun, Feb 25, 2007 at 05:50:11AM +0000, Christoph Hellwig wrote:
> global variables are very bad for code maintainability and understanadbility.
> So we usually try to avoid them if possible and make them static to a
> single file and provide proper accessors for allowed actions on them.

Another reason why mincing up code files into little-tiny itsy-bitsy
"units" to satisfy some vague abstraction fetish learned in CS101 is a
bad idea.  :-)

Seriously, abstractions have to be at the right layer in order for
them to add value, and too many abstractions (such as the time I
looked at a C++ toolkit with dozens of abstractions layers and
hundreds of itsy-bitsy files all adding a tiny amount of functionality
on top of each other) can be actively harmful.  If you group related
files together in a single C file, then it's possible to use static
per-file variables instead of global ones much more often.

In addition, another problem with global variables is that they by
destroy the ability to have multiple instances of the code referencing
running in different processors at the same time (unless they are
properly locked, adding a contention bottleneck).  So before ever
adding a global variable it is always important to ask how is this
protected from a locking point of view, and could it be linked off
some structure instead?

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