From owner-cvs-src@FreeBSD.ORG Wed Apr 21 22:19:53 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 680) id B4C2216A4CF; Wed, 21 Apr 2004 22:19:53 -0700 (PDT) Date: Wed, 21 Apr 2004 22:19:53 -0700 From: Darren Reed To: Max Laier Message-ID: <20040422051953.GA27025@hub.freebsd.org> References: <200404211527.i3LFRabS088245@repoman.freebsd.org> <6.0.1.1.1.20040422005919.03afaaa0@imap.sfu.ca> <20040422002143.GC60368@hub.freebsd.org> <200404220259.45651.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404220259.45651.max@love2party.net> User-Agent: Mutt/1.4.1i cc: cvs-src@FreeBSD.org cc: Luigi Rizzo cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Colin Percival Subject: Re: cvs commit: src/sys/net radix.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 05:19:53 -0000 On Thu, Apr 22, 2004 at 02:59:38AM +0000, Max Laier wrote: > > In the end: Yes it does! In this particular example I can easily tell > what the > new version does, while I wouldn't be able to tell it from > the first (w/o context). It just way easier to read, keeping it obscure > as all the other BSDs have it this way and it was this way for years > is just baloney. I would suggest that if you (or anyone else) has trouble reading the code, then read Stevens. The variable naming, etc, is not really the hard part of this code to grasp, it's the structures and how they interact and interconnect. Look in that book, see where all the arrows go in the diagrams. Perhaps I should say that having some understanding of how the radix/routing stuff works, just changing variable names does little in the way of making it more palatable. > To put some emphasis on why this will help locking, we don't have many brave > who happen to know from top to bottom and can > easily tell what "x = *(u_char *)p" is supposed to mean, but we have some who > have a good idea how to do locking. The changes Luigi is trying to do, should > enable better readability of the network code to make it possible for others > to lock things down. On the contrary, what you need is to understand the relationship between all the data structures and the who/what/where/how/why of their use. > I find readable code a good thing (even if it does not help locking). As does everyone else. > > In the end, if someone decides that the code needs to be restructured > > for better performance in SMP hardware, then that's what'll happen and > > changes like these will have little significance at that point in time. > > I don't think so. It's much easier to restructure code you can actually read > and understand. And honest, when one sees the current radix code (etc.), the > first thing that comes to mind is "run!". Same applies to IPv6/KAME-code, btw > - and I didn't see anybody to work on the locking there and I know a reason > why. Now now, don't be mean :) But don't forget that at least the way the radix code "was" had the backing of a number of chapters in a book that explain(ed/s) it all and so it has an advantage over IPv6/KAME... Darren