linux-kernel - Re: [PATCH 05/44 take 2] [UBI] internal common header

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]

Message-ID: <20070225115534.GA7989@thunk.org>
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/