code cleanup
Bruce Evans
bde at zeta.org.au
Thu Apr 29 05:04:32 PDT 2004
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
More information about the freebsd-current
mailing list