On Mon, Jun 10, 2002 at 10:02:21AM -0700, Linus Torvalds wrote:
> The linux coding style _tends_ to avoid using typedefs. It's not a hard
> rule (and I did in fact apply this patch, since it otherwise looked fine),
> but it's fairly common to use an explicit "struct xxxx" instead of
> "xxxx_t".
I agree. For a better future:
--- linux-2.5.21/Documentation/CodingStyle Mon Jun 10 20:29:26 2002
+++ linux-2.5.21/Documentation/CodingStyle Mon Jun 10 20:46:06 2002
@@ -264,3 +264,35 @@
Remember: if another thread can find your data structure, and you don't
have a reference count on it, you almost certainly have a bug.
+
+
+ Chapter 9: Typedefs
+
+You should avoid using typedefs. It's not a hard rule but it's fairly
+common to use an explicit "struct xxxx" instead of "xxxx_t".
+
+Hiding the fact that it's a struct causes bad things if people don't
+realize it: allocating structs on the stack is something you should be
+aware of (and careful with), and passing them as parameters is is much
+better done explicitly as a "pointer to struct".
+
+There are _some_ exceptions. For example, "pte_t" etc might well be a
+struct on most architectures, and that's ok: it's expressly designed to be
+an opaque (and still fairly small) thing. This is an example of where
+there are clear _reasons_ for the abstraction, not just abstraction for
+its own sake.
+
+For example, some people like to do things like:
+
+ /* BAD!!! */ typedef unsigned int counter_t; /* BAD!!! */
+
+and then use "counter_t" all over the place. I think that's not just ugly,
+but stupid and counter-productive. It makes it much harder to do things
+like "printk()" portably, for example ("should I use %u, %l or just %d?"),
+and generally adds no value. It only _hides_ information, like whether the
+type is signed or not.
+
+There is nothing wrong with just using something like "unsigned long"
+directly, even if it is a few characters longer than you might like. And
+if you care about the number of bits, use "u32" or something. Don't make
+up useless types that have no added advantage.
-- Dan Aloni da-x@gmx.netP.S. list_t was added between 2.5.1-pre9 and 2.5.1-pre10, when you applied Ingo's scalable scheduler code. Since then it gained a few users: device.h, fs.h, sched.h, and mm.h. It can be kicked out easily. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:18 EST