Messages in this thread | | | From | (Peter Benie) | Subject | Re: Headerless packets hitting ethernet? | Date | Mon, 27 Sep 1999 11:41:30 +0100 |
| |
Alan Cox writes ("Re: Headerless packets hitting ethernet?"): > > I'm not going to make myself popular here, but the network code is > > *not* easy to read. > > I'd agree > > > find some code that uses ip_rt_put. Cool, so the networking jargon > > for release is xxx_put(). > > > > So skb_put releases skbs then? Not fucking likely. kfree_skb does > > that: of course, it doesn't actually kfree the skb unless the refcnt > > If we suddenely swapped them for skb_alloc and skb_put every driver writer > would go ballistic
Changing the names now would be a crazy idea, but a few more comments in the code wouldn't go amiss.
A lot of the networking code is conceptually simple. There's a lot of it, which makes it tedious, but with a little time and patience, the code can be followed. However, every so often, you hit a function pointer, such as dst_entry.input or dst_entry.output. The problem with function pointers is that once you dereference one, to understand the code, you need to find where and why the pointer was set. A few lines of comments pointing people in the right direction would be incredibly helpful. Without them, the code has the property that to understand a small part of the code, you need to understand _all_ of the code, which is a bad property, both for reliablility and for security. I don't agree with Alexey's argument that the complex code is just an exam; I certainly wouldn't push for changing the code to make it easier for newbie programmers, but the existing code is tough even for experienced programmers.
Even if you have read all the code and understand what the existing code does right now, it is impossible to deduce from the code what the expected semantics of an interface are. This makes it difficult to write code that will stay working in future versions of the kernel. Without documentation, you have to understand how different parts of the kernel interact with each other, and as the code gets bigger and acquires more subsystems, this becomes a much harder task - the complexity of the interactions goes up much faster than the size of the code. With documented interfaces, it would be possible to find bugs by checking that the code on both sides of an interface obey the documented semantics and don't rely on undocumented semantics. Note that I'm not advocating setting kernel internal interfaces in stone, but I do want interfaces to be more obvious so people think harder about the consequences for other people's code when they change the semantics.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |