lkml.org 
[lkml]   [1999]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Headerless packets hitting ethernet?
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.126 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site