Date: Thu, 29 Apr 2004 15:28:38 +0300 From: Alex Lyashkov <shadow@psoft.net> To: Bruce Evans <bde@zeta.org.au> Cc: Julian Elischer <julian@elischer.org> Subject: Re: code cleanup Message-ID: <1083241717.25424.7.camel@berloga.shadowland> In-Reply-To: <20040429214942.T11397@gamplex.bde.org> References: <Pine.BSF.4.21.0404281120480.73191-100000@InterJet.elischer.org> <200404281541.08851.jhb@FreeBSD.org> <20040429214942.T11397@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=F7 =FE=D4=D7, 29.04.2004, =D7 15:04, Bruce Evans =D0=C9=DB=C5=D4:
> On Wed, 28 Apr 2004, John Baldwin wrote:
>=20
> > 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, bu=
t
> > > > > 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 thi=
nk
> > > > hiding the fact that it's a TAILQ is all that useful.
>=20
> I'd rather it had never been.
>=20
> > > 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).
>=20
> This macro seemed more reasonable when it was added because its scope
> was limited and I thought it was temporary.
>=20
> > 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 g=
reps.
> > When you multiple the effect with several wrapper macros, it now become=
s 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.
>=20
> 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.
>=20
> Bruce
who prevent have special define for debug allproc list (as witness) ?=20
if it`s defined macros add additional checks inside.
you can define it only for one c file.
--=20
Alex Lyashkov <shadow@psoft.net>
PSoft
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1083241717.25424.7.camel>