From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 05:04:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F64816A4CE; Thu, 29 Apr 2004 05:04:32 -0700 (PDT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F02C43D1D; Thu, 29 Apr 2004 05:04:29 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i3TC4O4u025402; Thu, 29 Apr 2004 22:04:24 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i3TC4KI2014914; Thu, 29 Apr 2004 22:04:21 +1000 Date: Thu, 29 Apr 2004 22:04:18 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin In-Reply-To: <200404281541.08851.jhb@FreeBSD.org> Message-ID: <20040429214942.T11397@gamplex.bde.org> References: <200404281541.08851.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "freebsd-current@freebsd.org" cc: Julian Elischer cc: Alex Lyashkov Subject: Re: code cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2004 12:04:32 -0000 On Wed, 28 Apr 2004, John Baldwin wrote: > On Wednesday 28 April 2004 02:26 pm, Julian Elischer wrote: > > On Wed, 28 Apr 2004, John Baldwin wrote: > > > On Wednesday 28 April 2004 02:26 am, Alex Lyashkov wrote: > > > > Hi All > > > > > > > > how i see many points at kernel work with allproc list direct, but > > > > proc.h introduce macros FOREACH_PROC_IN_SYSTEM. > > > > This patch clean this places. > > > > > > I'd actually rather see the FOREACH_PROC macro removed, I don't think > > > hiding the fact that it's a TAILQ is all that useful. I'd rather it had never been. > > it makes it possible (well, easier) to do: > > > > FOREACH_PROC_IN_SYSTEM(p) { > > FOREACH_KSEGROUP_IN_PROC(p, kg) { > > FOREACH_THREAD_IN_GROUP(kg.td) { > > something(td, kg); > > } > > } > > } > > > > Which is a lot easier to read and understand > > than the expanded version. You don't kave to remember the linkage > > pointer's names and you can add debugging to it > > and check that the correct loks are held etc. > > (the latter being a major reason I did it). This macro seemed more reasonable when it was added because its scope was limited and I thought it was temporary. > Note that the allproc_lock protects the allproc list. W/o the FOREACH_PROC > macro, I can grep for 'allproc' in the source tree to find all users to > verify locking, etc. With the extra macro, I now have to do multiple greps. > When you multiple the effect with several wrapper macros, it now becomes much > more work to work on locking the lists of structures since you have to do > multiple greps to find the places to look at. I think remembering the > linkages for lists is actually quite important to avoid using the same > linkage for multiple lists incorrectly. Macros are bad for debugging. The above is a sort of high level aspect of debugging. One low level one is when need to look at the linkages for the lists. Bruce