Ending the list_t scourge
Recently, a typedef (list_t) was added as an equivalent name for the list_head structure; rumor has it Ingo Molnar added the name to help keep his source lines within 80 columns. One would think that people would not get overly worked up about this addition, but this is the kernel hacker community we are dealing with. The prevailing opinion among kernel hackers has swung strongly against typedef in recent times. Use of typedef is seen as a useless hiding of information that programmers need to see. Defined types also complicate include file dependencies. Structures can be "predeclared" with a line like:
struct my_struct;and references to that structure (pointers, in particular) can be used as long as the internals of the structure are not accessed. Defined types can not be predeclared in this way, making it harder to mix mutually-dependent types across files.
So Rusty Russell posted a patch which removes
list_t from the kernel. Nobody really complained about that
change, but some wondered: why not rename the list_head structure
to struct list at the same time. As William Irwin rather
graphicly put it: "Throw the whole frog
in the blender, please, not just half.
"
In the end, a big renaming of struct list_head throughout the
kernel tree (and external code) wasn't to most peoples' taste. And Linus
isn't into blended frogs. So the patch
removing list_t went into Linus's BitKeeper tree (and will be in
2.5.34), but struct list_head remains.
Posted Sep 5, 2002 14:29 UTC (Thu)
by unaiur (guest, #3563)
[Link] (1 responses)
Posted Sep 6, 2002 10:32 UTC (Fri)
by Phaeton (guest, #3579)
[Link]
Someone with a loud voice had a big opinion, Yes, I see that some people prefer to know that Pity with linux is that the core can't seem to
typedef can also be predeclared:Ending the list_t scourge
struct list_head;
typedef struct list_head list_t;
Well, the Kernel hacker community seems to beEnding the list_t scourge
a good soil for heated discussions, partially
leaving technical aspects, or such with good
foundation out.
and that's why it's going that way now...
the type they're handling IS a struct; and that
is a good reason. Predeclaring isn't, as you
have shown.
reach an agreement basing on technical facts
only - which is its greatest weakness I assume.